}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Grafický modul systému pro rˇízení svˇetelné signalizace ˇ B AKALÁ RSKÁ PRÁCE
Martina Vitovská
Brno, Jaro 2015
Prohlášení Prohlašuji, že tato bakaláˇrská práce je mým puvodním ˚ autorským dílem, které jsem vypracovala samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používala nebo z nich cˇ erpala, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.
Martina Vitovská
Vedoucí práce: RNDr. Jaroslav Pelikán, Ph.D. ii
Podˇekování Tímto bych chtˇela podˇekovat RNDr. Jaroslavu Pelikánovi, Ph.D. za vedení této bakaláˇrské práce a pˇredevším za ochotu a pomoc pˇri její tvorbˇe.
iii
Shrnutí Tato práce se zabývá vývojem modulu do aplikace pro tvorbu dopravních rˇ ešení. Modul umožnuje ˇ vytvoˇrit dopravní algoritmus pomocí vývojového diagramu. Diagram je následnˇe pˇreveden do zdrojového kódu v jazyce C a pˇreložen do objektového kódu pro procesor ARM, operaˇcní systém Linux. Práce také popisuje problematiku tvorby signálních plánu, ˚ ze které vyplývá duvod ˚ pro vývoj tohoto modulu.
iv
Klíˇcová slova vývojový diagram, dopravní rˇ ešení, dopravní algoritmus, rˇ adiˇc svˇetelné signalizace, signální plán, Windows Forms, C
v
Obsah 1 2
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . Dopravní východisko . . . . . . . . . . . . . . . . 2.1 Základní pojmy . . . . . . . . . . . . . . . . . ˇ 2.2 Radiˇ c svˇetelné signalizace . . . . . . . . . . . 2.3 Problém tvorby signálních plánu˚ . . . . . . . 2.4 Souˇcasný stav a návrh rˇ ešení . . . . . . . . . 2.5 Princip dopravního rˇ ízení . . . . . . . . . . . 3 Popis grafického modulu . . . . . . . . . . . . . . 3.1 Diagram pˇrípadu˚ užití . . . . . . . . . . . . . 3.2 Dopravní program . . . . . . . . . . . . . . . 3.3 Vývojový diagram . . . . . . . . . . . . . . . 3.4 Práce s pˇríkazy a podmínkami . . . . . . . . 4 Implementace . . . . . . . . . . . . . . . . . . . . . 4.1 Prostˇredky a vstupní parametry . . . . . . . . 4.2 Základní tˇrídy . . . . . . . . . . . . . . . . . . 4.3 Grafická reprezentace vývojového diagramu 4.4 Tvorba vývojového diagramu . . . . . . . . . 4.5 Výrazy a podmínky . . . . . . . . . . . . . . . 4.6 Ukládání a naˇcítání vytvoˇrených programu˚ . 4.7 Zabezpeˇcení souboru XML . . . . . . . . . . 4.8 Syntaktická analýza hlaviˇckových souboru˚ . 4.9 Generování zdrojového kódu . . . . . . . . . 4.10 Pˇreklad . . . . . . . . . . . . . . . . . . . . . . 5 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . A Ukázka navrženého dopravního rˇešení . . . . . . B Úpravy pro bakaláˇrskou práci a instalace . . . . . C Elektronické pˇrílohy . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
1 2 2 3 5 6 8 11 11 13 14 15 16 16 17 20 20 22 23 25 25 28 28 30 33 40 41
vi
Seznam obrázku˚ 2.1 2.2
ˇ Cásti rˇ adiˇce svˇetelné signalizace 4 Výstup modulu 8
3.1
Diagram pˇrípadu˚ užití 11
4.1 4.2 4.3 4.4
Diagram tˇríd – základní tˇrídy 17 Diagram tˇríd – tˇrídy vývojového diagramu 18 Vývojový diagram 21 Diagram tˇríd – analyzátor hlaviˇckových souboru˚ 26
A.1 A.2 A.3 A.4
Vývojový diagram funkce preLogic() 36 Vývojový diagram funkce mainLogic() 37 Vývojový diagram funkce FAZE1() 38 Vývojový diagram funkce FAZE2() 39
vii
1 Úvod Svˇetelné kˇrižovatky jsou v dopravˇe již samozˇrejmostí. Na kˇrižujících komunikacích nastávají velmi cˇ asto složité situace, které by bylo obtížné rˇ ešit jiným zpusobem. ˚ Pro zvládnutí tˇechto situací pomocí svˇetelných signalizaˇcních zaˇrízení je však nutné sestavit algoritmus, který zajistí fungování celé kˇrižovatky a bezpeˇcný prujezd ˚ pro úˇcastníky provozu. Na tvorbˇe takového algoritmu se musí podílet dopravní inženýr, který má s touto problematikou zkušenosti. Pˇri implementaci se totiž vychází i ze stavebních možností kˇrižovatky a z legislativních požadavku. ˚ Dopravní inženýr pak navrhne rˇ ešení, které však vˇetšinou nedokáže sám zrealizovat. Procesu se tedy musí úˇcastnit další osoba, a to programátor. Cílem této bakaláˇrské práce bylo vytvoˇrit nástroj, který dopravnímu inženýrovi dovolí algoritmus sestavit pomocí vývojového diagramu, poté diagram pˇrevede do kódu v jazyce C a program pˇreloží. Nástroj byl navržen tak, aby se dopravní inženýr co nejménˇe setkával s pojmy týkajícími se konkrétního programovacího jazyka. Díky tomu muže ˚ být programátor z celého procesu realizace dopravního rˇ ešení vynechán. Text bakaláˇrské práce je rozdˇelen do pˇeti kapitol. Ve druhé kapitole jsou uvedeny nˇekteré pojmy z oblasti rˇ ízení svˇetelné signalizace, které jsou v textu pozdˇeji používány. Následuje úvod do problematiky tvorby dopravních rˇ ešení, ze které vyplývá úˇcel této bakaláˇrské práce. Tˇretí kapitola se vˇenuje modulu z pohledu uživatele. Jsou uvedeny hlavní pˇrípady užití a vysvˇetlení, jakým zpusobem ˚ modul funguje. Ve cˇ tvrté kapitole jsou nejprve popsány vstupní parametry modulu, základní tˇrídy modulu a poté hlavní body implementace. Pátá kapitola obsahuje shrnutí celé bakaláˇrské práce a jsou v ní navrženy možnosti budoucího vývoje modulu.
1
2 Dopravní východisko V této kapitole je objasnˇen smysl modulu pro tvorbu dopravních algoritmu˚ pomocí vývojových diagramu. ˚ Jsou v ní vysvˇetleny základní pojmy potˇrebné pro pochopení cˇ innosti dopravního inženýra, problematika signálních plánu˚ a také princip, jakým je vytvoˇrený dopravní algoritmus zpracován. Je zde také popsán souˇcasný stav týkající se tˇechto algoritmu˚ a nastínˇeno rˇ ešení. Kapitola byla vypracována ve spolupráci s firmou CROSS Zlín a.s. a podle firemních materiálu˚ [1].
2.1
Základní pojmy
ˇ ce svˇetelné signalizace (ˇradiˇce SSZ) jsou elektronická zaˇrízení, kteRadiˇ rá slouží k rˇ ízení provozu na kˇrižovatkách pozemních komunikací nebo pˇrechodu˚ pro chodce pomocí svˇetelných signálu. ˚ Pˇri rˇ ízení dopravy je základním pojmem signální skupina. Jedná se o skupinu návˇestidel pro urˇcitý smˇer jízdy. Návˇestidlo je zaˇrízení, které vizuálnˇe pˇredává pokyny úˇcastníkum ˚ provozu. Veškeré rˇ ízení se pak odehrává na úrovni zasílání signálu˚ „volno“ a „stuj“ ˚ jednotlivým signálním skupinám. Z duvodu ˚ bezpeˇcnosti je duležitou ˚ souˇcástí dopravního rˇ ešení práce s meziˇcasy. Meziˇcas je cˇ asový údaj (v sekundách), který udává, jaký nejkratší cˇ as je povolen mezi ukonˇcením stavu „volno“ jedné signální skupiny a zahájením stavu „volno“ jiné signální skupiny. Tyto údaje se zapisují formou tabulky nazývané tabulka meziˇcasu. ˚ Pro kombinaci dvou skupin existují vždy dva meziˇcasy, každá skupina je jednou vyklizující (ukonˇcení stavu „volno“) a jednou najíždˇející (zahájení stavu „volno“). V dopravním algoritmu je nutné poˇcítat s tím, že hodnoty meziˇcasu˚ nemohou být porušeny. Pokud mezi dvˇema skupinami není meziˇcas, znamená to, že mohou být ve stavu „volno“ souˇcasnˇe. V praxi se obvykle nepracuje s každou signální skupinou samostatnˇe, ale skupiny se sdružují do fází, protože ve stavu „volno“ bývá obvykle nˇekolik signálních skupin souˇcasnˇe. Fáze je tedy cˇ asové období, kdy je ve stavu „volno“ nˇekolik signálních skupin (i v pˇrí2
2. D OPRAVNÍ VÝCHODISKO padˇe, že trvání stavu „volno“ není stejné pro všechny skupiny, které fáze obsahuje). Pokud je ukonˇcena jedna fáze a rˇ ízení pˇrechází do jiné fáze, dochází k pˇrechodu pˇres stav „stuj“ ˚ u jednotlivých skupin tak, aby byly zajištˇeny meziˇcasy. Tomuto pˇrechodovému cˇ asu se rˇ íká fázový pˇrechod. Ovládání svˇetelných signalizaˇcních zaˇrízení definuje dopravní inženýr vytvoˇrením dopravního algoritmu, který je zpracován ve formˇe signálního plánu. Signální plán je pˇredpis, jakým zpusobem ˚ jsou v cˇ ase pˇrepínány jednotlivé stavy svˇetelných zaˇrízení a jehož smyslem je docílit maximálního poˇctu projetých vozidel ve všech rˇ ízených smˇerech, minimalizovat cˇ ekací doby jednotlivých úˇcastníku˚ silniˇcního provozu a také zajistit bezpeˇcnost dopravy. To vše za dodržení pravidel, která vyplývají z legislativních požadavku, ˚ požadavku˚ zadavatele rˇ ešení a stavebních možností kˇrižujících komunikací. Pro optimalizaci rˇ ízení kˇrižovatky se využívají takzvané detekˇcní systémy. Jedná se o soubor zaˇrízení urˇcených pro sledování potˇrebných informací o úˇcastnících provozu. Nejˇcastˇeji se jedná o detekci vozidel v urˇcitých místech kˇrižovatky, dále o detekci stisknutí tlaˇcítek u pˇrechodu˚ pro chodce.
2.2
ˇ Radiˇ c svˇetelné signalizace
ˇ Radiˇ c svˇetelné signalizace se skládá z následujících cˇ ástí: Napájecí zdroj: slouží k napájení ostatních cˇ ástí rˇ adiˇce. Základní procesorová jednotka: centrální obvod, složený z procesoru (nejˇcastˇeji 32bitový ARM Cortex-A5 [2]), pamˇeti RAM (desítky až stovky MB), obvodu˚ reálného cˇ asu, USB rˇ adiˇce, rozhraní Ethernetu, SD karty a rozhraní sériové komunikace. V procesorové jednotce bˇeží operaˇcní systém Linux a pod ním základní ovládací firmware, který zajišt’uje pˇrístup k hardwaru (vstupní a výstupní obvody), bˇeh dopravních algoritmu, ˚ procesy bezpeˇcnostní kontroly, komunikaci s jinými periferiemi a rozhraní pro nadˇrízené systémy (napˇríklad pro rˇ ídící centrálu). Pamˇet’ové médium (SD karta): slouží k uložení operaˇcního systému Linux, aplikací a trvalých dat. 3
2. D OPRAVNÍ VÝCHODISKO
ˇ Obrázek 2.1: Cásti rˇ adiˇce svˇetelné signalizace Vstupní obvody: zajišt’ují sbˇer informací z detekˇcního systému. Výstupní obvody: slouží k pˇrevedení signálu˚ rˇ ízení na barevný obraz reprezentovaný návˇestidlem (semaforem). Výstupní obvod souˇcasnˇe zajišt’uje informaci, zda bylo pˇrepnutí svˇetla bezchybnˇe uskuteˇcnˇeno (kontrolou pˇríkonu). Sbˇernice: veškeré cˇ ásti rˇ adiˇce jsou propojeny sériovou sbˇernicí (CAN [3], RS485 [4] atd.). Kontrolní jednotka: druhá nezávislá procesorová jednotka sloužící ke kontrole bˇehu základní procesorové jednotky. Neustále na sbˇernici monitoruje pˇríkazy základní procesorové jednotky a na základˇe bezpeˇcnostních pravidel vyhodnocuje správnost pˇríkazu˚ pro výstupní obvody. V okamžiku zjištˇení chyby nebo nesouladu vyvolá poruchový stav celého zaˇrízení (kmitavá žlutá, pˇrípadnˇe celkové vypnutí zaˇrízení). Hlídání kontrolní a základní jednotky je vzájemné – pokud základní jednotka 4
2. D OPRAVNÍ VÝCHODISKO zjistí poruchu kontrolní jednotky, celé zaˇrízení je uvedeno do poruchového stavu. Toto rˇ ešení vyplývá z požadavku bezpeˇcnostní normy SIL3 [5], ze stejného duvodu ˚ jsou v tˇechto jednotkách použity jiné typy procesoru, ˚ jiné programovací nástroje (pˇrekladaˇce) a jsou jiní autoˇri softwaru. Komunikaˇcní rozhraní: zajišt’uje komunikaci s dalšími periferiemi (napˇríklad GPS, GSM modem, radiový modem apod.) Firmware základní a kontrolní jednotky je zavádˇen zcela nezávislým zpusobem ˚ a vždy obsahuje bezpeˇcnostní definici, která slouží k porovnání a posouzení pˇríkazu. ˚ Tato bezpeˇcnostní definice obsahuje hardwarové nastavení celého rˇ adiˇce, typy signálních skupin a tabulku meziˇcasu. ˚ Jakýkoliv nesoulad bezpeˇcnostních definic mezi jednotkami znemožní spuštˇení dopravního rˇ ešení. Firmware kontrolní jednotky nelze zavádˇet vzdálenˇe (pomocí Ethernetu nebo GSM sítˇe) na rozdíl od firmwaru základní procesorové jednotky. Zmˇeny dopravního rˇ ešení nevedou ke zmˇenˇe bezpeˇcnostní definice.
2.3
Problém tvorby signálních plánu˚
Dopravní rˇ ešení je v rˇ adiˇci realizováno formou signálního plánu. Nejjednodušším druhem signálního plánu je pevný signální plán. Tento plán pˇrepíná stavy jednotlivých signálních skupin v pravidelnˇe se opakujícím cˇ asovém intervalu. Dopravní inženýr tedy pouze zadá nˇekolik nutných parametru, ˚ jako jsou délka cyklu a poˇradí jednotlivých svˇetelných signálu. ˚ Výhodou pevného plánu je snadná logika rˇ ízení kˇrižovatky, kterou lze jednoduše zmˇenit, a také pˇredvídatelnost délky signálu „volno“ jednotlivých signálních skupin, což umožnuje ˇ koordinaci signálu˚ pˇrilehlých kˇrižovatek. Není však zohlednˇena intenzita provozu a muže ˚ se stát, že vozidla z jednoho smˇeru cˇ ekají na signál „volno“, i když v druhém smˇeru žádná vozidla neprojíždí. Dalším problémem jsou pˇrechody pro chodce. Na kˇrižovatkách rˇ ízených pevnými signálními plány vˇetšinou nebývají k dispozici tlaˇcítka pro chodce, a cˇ asto tedy svítí signál „volno“ i v pˇrípadˇe, kdy nikdo kˇrižovatku nepˇrechází. Tyto problémy rˇ eší složitˇejší signální plán, a to plán dynamický. Aktuální dopravní situaci lze totiž sledovat pomocí detekˇcních sys5
2. D OPRAVNÍ VÝCHODISKO tému. ˚ Získané údaje se následnˇe využívají v dopravním algoritmu, který je souˇcástí dynamického signálního plánu. Tento plán je tedy již program, který na základˇe vstupních podmínek urˇcuje stav svˇetelného signalizaˇcního zaˇrízení a pro který je nutné alesponˇ cˇ ásteˇcnˇe dopravní algoritmus implementovat. Velká cˇ ást algoritmu˚ se sice opakuje, a proto lze nˇekterá data definovat parametricky, nezanedbatelnou cˇ ást definic je však nutné doplnit pomocí kódu. První dynamické plány byly do rˇ adiˇcu˚ vkládány v hexadecimálním kódu, pozdˇeji v jazyce symbolických adres. Další vývoj smˇerˇ oval k programovacím jazykum ˚ C a C++, které se staly nejpoužívanˇejšími jazyky pro psaní kódu dynamických signálních plánu, ˚ pˇrestože nˇekteré firmy dávají pˇrednost modernˇejším jazykum ˚ jako je Java nebo Lua [6]. Požadavek na implementaci dopravního algoritmu však znamená, že na tvorbˇe signálního plánu se bude podílet kromˇe dopravního inženýra i programátor nebo se dopravní inženýr nauˇcí syntaxi jazyka vyžadovaného pro daný typ rˇ adiˇce svˇetelné signalizace. Obˇe varianty mají své nevýhody. Zapojení programátora do práce na signálním plánu znamená dražší rˇ ešení a cˇ asto dochází k nepochopení zámˇeru dopravního inženýra. Pokud pˇripravuje plán pouze dopravní inženýr, nedochází k chybám kvuli ˚ nepochopení, ale kvuli ˚ nedokonalé znalosti konstrukcí programovacího jazyka. Aˇckoli jsou tedy dynamické plány optimálním rˇ ešením rˇ ízení svˇetelné signalizace, tak se kvuli ˚ zmínˇeným problémum ˚ historicky nerozšíˇrily. Nejˇcasˇ tˇeji se používají v Nˇemecku, Holandsku a Ceské republice.
2.4
Souˇcasný stav a návrh rˇešení
Firma CROSS Zlín a.s., dodavatel technologií pro rˇ ízení a monitorování dopravy, je výrobcem rˇ adiˇcu˚ SSZ rˇ ady RS, které jsou pˇripraveny a využívány pro dynamické signální plány. V souˇcasné dobˇe umožnuje ˇ jak parametrické programování (pˇreddefinovaný rozsáhlý dopravní algoritmus s mnoha parametry), tak i vytváˇrení programu˚ v jazyce C. Vzhledem k postupnému rozšíˇrení dodávek rˇ adiˇcu˚ SSZ do celého svˇeta se stalo nutností doplnˇení nového návrhového prostˇredí pro tvorbu dynamických signálních plánu. ˚ Výchozím stavem je aplikace CROSS-PTC, která rˇ eší veškeré práce s kˇrižovatkou a rˇ adiˇcem SSZ. Slouží k evidenci jednotlivých kˇri6
2. D OPRAVNÍ VÝCHODISKO žovatek, jejich definic z topologického a dopravního hlediska a definic objektu˚ rˇ adiˇce SSZ (signální skupiny, detektory, plány atd.). Mezi další funkce aplikace patˇrí: •
výpoˇcty dopravních závislostí a hodnot na základˇe dopravních zátˇeží
•
návrh dopravního rˇ ízení formou zadávání parametru˚
•
výpoˇcty a hodnocení navržených dopravních rˇ ešení
•
zavádˇení dopravních rˇ ešení do rˇ adiˇce SSZ
•
zpracování statistických dat kˇrižovatky (poˇcty vozidel, kategorizace, preference MHD)
•
propojení s programy pro simulaci dopravy
V aplikaci lze definovat práva pro dopravní inženýry, pracovníky výroby rˇ adiˇcu˚ SSZ, servis kˇrižovatek apod. tak, aby mˇel každý k dispozici prostˇredky potˇrebné ke své práci. Veškeré zmˇeny jsou organizovány systémem archivních, aktuálních a pracovních verzí s možností provedení porovnání mezi verzemi. Aplikace je napsána v jazyce C# v prostˇredí MS Visual Studio a lze ji snadno doplnovat ˇ o další moduly. Novým modulem k této aplikaci je nástroj PTCModul, který je pˇredmˇetem této bakaláˇrské práce a který dopravního inženýra odstíní od nutnosti tvorby kódu v jazyce rˇ adiˇce a studia syntaxe knihovních funkcí rˇ adiˇce. Modulem je prostˇredí, které dovoluje dopravní algoritmus navrhnout formou grafického návrhu vývojového diagramu s použitím co nejjednodušších konstrukcí, jako jsou napˇríklad pˇriˇrazení, podmínka nebo cyklus, a které uživateli pˇredkládá dopravní funkce rˇ adiˇce svˇetelné signalizace formou nabídek vytvárˇ ených z hlaviˇckových souboru˚ dodávaných k rˇ adiˇci. Dále modul umožnuje ˇ výsledný vývojový diagram pˇrevést do kódu v jazyce C. Díky tomu není od dopravního inženýra vyžadována témˇerˇ žádná znalost programovacího jazyka. Kód v jazyce C je pˇreložen do objektového souboru, který je komprimován do souboru .tgz a v této podobˇe je zaveden do rˇ adiˇce SSZ (viz. obrázek 2.2). 7
2. D OPRAVNÍ VÝCHODISKO
Obrázek 2.2: Výstup modulu Aby bylo možné pˇripravit takový modul, je nutné, aby byli jak tvurce ˚ modulu, tak i jeho uživatel seznámeni s principem dopravního rˇ ízení pomocí signálního plánu. Základní princip je na rozdíl od vlastních dopravních algoritmu˚ velmi jednoduchý.
2.5
Princip dopravního rˇízení
Dopravní rˇ ízení (prubˇ ˚ eh signálního plánu) probíhá v pˇresnˇe stanovených krocích. Témˇerˇ výhradnˇe se používá jedna sekunda jako cˇ as, ve kterém dojde k vyhodnocení dopravní situace, reakci a zmˇenˇe stavu˚ signálních skupin a tím i svˇetel. Aby byly splnˇeny požadavky norem, je celé vyhodnocení provádˇeno v jednom co nejpˇresnˇeji definovaném okamžiku intervalu (dopravní sekundy), což se uskuteˇcnuje ˇ pomocí hardwarového cˇ asovaˇce, který umožnuje ˇ pˇrerušovat v reálném cˇ ase bˇeh operaˇcního systému Linux. Tím je zajištˇeno, že ke zmˇenˇe signálního obrazu (stavu signálních skupin) dojde vždy za jednu sekundu s maximální odchylkou 10 %. Vlastní dopravní vyhodnocení každé sekundy probíhá ve tˇrech krocích (ve tˇrech funkcích Logic): PreLogic: pˇrípravná fáze dopravního rˇ ízení, naˇctení stavu detektoru, ˚ výpoˇcty. MainLogic: hlavní zpracování dopravního rˇ ízení, pˇríkazy pro zmˇeny logického stavu signálních skupin. 8
2. D OPRAVNÍ VÝCHODISKO PostLogic: koneˇcné zpracování stavu signálních skupin. Požadavky jsou zpracovány tak, aby byla dodržena bezpeˇcnostní pravidla. Tzn. pokud byl v MainLogic dán požadavek na stav „stuj“, ˚ tak je kontrolováno, zda je splnˇena minimální doba stavu „volno“, zda je realizován pˇrechodový stav mezi stavem „volno“ a „stuj“ ˚ (žlutá pro vozidla) a zda je dodržena tabulka meziˇcasu. ˚ Výsledný stav tak muže ˚ být i po pomˇernˇe dlouhé dobˇe rozdílný od požadovaného stavu (jednotky až desítky sekund). V dobˇe provozu svˇetelné signalizace jsou vyvolávány všechny tˇri kroky rˇ ízení, v dobˇe, kdy je svˇetelná signalizace ve stavu kmitavá žlutá nebo tma, je vyvoláván pouze krok PostLogic. Za provozu jsou pak v tˇechto krocích zpracovávány parametry signálních plánu˚ pomocí pevnˇe naprogramovaného dopravního algoritmu. Parametrický algoritmus lze upravit nebo až nahradit ovlivnˇením jednotlivých kroku˚ pomocí následujícího mechanismu: Firmware rˇ adiˇce v jednotlivých krocích vždy volá pˇreddefinované knihovní funkce PreLogic, MainLogic a PostLogic, které jsou standardnˇe prázdné a nemají žádnou výkonnou cˇ ást. Dodateˇcnˇe lze ale doplnit knihovnu s tˇemito funkcemi a v tu chvíli budou v jednotlivých krocích logiky použity tyto novˇe vložené funkce. Dopravní inženýr nebo programátor muže ˚ vytvoˇrit tyto funkce podle své potˇreby, vložit do nich nové dopravní algoritmy nebo výpoˇcty a zcela dostat pod kontrolu celé dopravní rˇ ešení. Jediným omezením je: •
bezpeˇcnostní kontrola – nelze obejít bezpeˇcnostní mechanismy, které mu zabrání vyprodukovat nebezpeˇcný stav (kolizní zelené apod.)
•
cˇ asová kontrola – cˇ as strávený v napsané funkci – je hlídána maximální doba, aby nebylo ovlivnˇeno cˇ asování dopravní sekundy (nekoneˇcné cykly apod.) Pˇri tvorbˇe funkcí má dopravní inženýr k dispozici:
•
hlaviˇckový soubor, který obsahuje definici všech objektu˚ rˇ adicˇ e SSZ (signální skupiny, signální plány, detektory atd.). Tento soubor je vytváˇren pro každý rˇ adiˇc SSZ a vždy znovu pˇri každé zmˇenˇe objektu. ˚ 9
2. D OPRAVNÍ VÝCHODISKO •
hlaviˇckové soubory s deklarací všech dopravních funkcí, které muže ˚ inženýr využívat pˇri tvorbˇe logiky. Tyto funkce jsou jak dotazovací (zjišt’ování údaju˚ o jednotlivých objektech), tak pˇríkazové (pˇríkazy ke zmˇenˇe stavu objektu˚ nebo celého rˇ adiˇce SSZ). Tyto soubory jsou platné pro všechny rˇ adiˇce SSZ, mˇení se ale se zmˇenou verze firmwaru rˇ adiˇce, protože jsou cˇ asto doplnovány ˇ nové funkce. Je však vždy dodržena zpˇetná kompatibilita (staré funkce zustávají ˚ s puvodní ˚ deklarací, pouze jsou pˇridávány funkce nové). Pomocí tˇechto dopravních funkcí lze zapsat celou dopravní logiku, napˇríklad: Zaˇrazení stavu „volno“ pro chodce po stisknutí chodeckého tlaˇcítka (pokud byl požadavek na detektoru „tlacitko“, nastav stav „volno“ pro signální skupinu „chodec“): i f ( DetAnfo ( t l a c i t k o ) ) SgrAn ( chodec ) ; Názvy funkcí jsou cˇ asto pˇrevzaty z cizích standardu˚ (pˇrevážnˇe nˇemeckých), ale každá funkce má v hlaviˇckovém souboru komentáˇr s popisem.
Firmware rˇ adiˇce umí zpracovat zavedení funkcí Logic z objektových souboru˚ (pˇrípona .o) tak, že pokud objeví nové verze tˇechto funkcí, zaˇcne je používat. Zavedení tˇechto funkcí je možné provést i za bˇehu bez nutnosti ukonˇcení firmwaru. Ke zmˇenˇe dopravní logiky jsou tedy nutné kroky: •
pˇripravit zdrojový soubor obsahující funkce Logic s využitím uvedených hlaviˇckových souboru˚
•
provést pˇreklad do objektového kódu pro procesor ARM
•
pˇrenést objektový soubor do rˇ adiˇce pomocí servisní aplikace
Poslední krok je nejjednodušší, aplikace je k tomuto úˇcelu již pˇripravena, staˇcí uvedený soubor uložit do složky definice rˇ adiˇce. Pˇríprava zdrojového souboru v jazyce C a kˇrížového pˇrekladu do objektového kódu pro konkrétní procesor jsou pro dopravní inženýry znaˇcnou komplikací. 10
3 Popis grafického modulu Tato kapitola se vˇenuje popisu funkcí modulu z pohledu uživatele. Nejprve je pˇrehled funkcí uveden pomocí diagramu pˇrípadu˚ užití, poté je modul popsán detailnˇeji v jednotlivých cˇ ástech kapitoly.
3.1
Diagram pˇrípadu˚ užití
Obrázek 3.1: Diagram pˇrípadu˚ užití
11
3. P OPIS GRAFICKÉHO MODULU Popis aktéru: ˚ •
Dopravní inženýr (uživatel) – inženýr, který pomocí modulu navrhuje dopravní program pro danou kˇrižovatku. Neoˇcekává se od nˇeho žádná znalost programovacího jazyka.
Popis pˇrípadu˚ užití: •
Založit program – založení nového dopravního programu, který pˇredstavuje jeden zdrojový soubor s pˇríponou .c.
•
Pˇridat/odebrat funkci do/z programu – uživatel má možnost pˇridávat/odebírat vlastní funkce (odpovídající funkcím v jazyce C) do/z programu.
•
Pˇridat/odebrat promˇennou do/z programu/funkce – možnost pˇridávat nebo odebírat globální nebo lokální promˇenné.
•
Vytvoˇrit vývojový diagram – tvorba vývojového diagramu vˇcetnˇe sestavení pˇríkazu˚ a podmínek.
•
Uložit diagram – uložení vývojového diagramu do souboru XML. Cesta k adresáˇri, který slouží pro uložení souboru, je pˇredávána jako vstupní parametr modulu. Místo pro uložení tedy nelze zvolit, protože je pracovní adresáˇr vybrán v aplikaci ještˇe pˇred spuštˇením modulu.
•
Pˇrevést na kód a pˇreložit – pˇrevod vývojového diagramu do zdrojového souboru v jazyce C a jeho pˇreklad pro procesor architektury ARM. Soubor je uložen do stejného adresáˇre jako soubor XML.
•
Zobrazit kód – zobrazení vytvoˇreného zdrojového souboru s vyznaˇcenými klíˇcovými slovy.
•
Zobrazit log – zobrazení logu, který byl vytvoˇren pˇri pˇrekladu, se zvýraznˇenými chybami pˇrekladu a varováními. 12
3. P OPIS GRAFICKÉHO MODULU
3.2
Dopravní program
Základem je dopravní program obsahující funkce, které muže ˚ dopravní inženýr sám vytváˇret. Uživatel má ke každé funkci možnost zvolit její název a návratový typ a sestavit seznam vstupních parametru. ˚ Po založení má program tˇri funkce – preLogic(), mainLogic() a postLogic(). Tyto funkce musí být souˇcástí každého dopravního programu, a proto je není možné odstranit (viz. kapitola 2.5). Do programu lze pˇridávat vlastní globální promˇenné (a poté je upravovat nebo z programu odebírat), které je možné použít ve všech funkcích, a také lokální promˇenné, které jsou unikátní pro každou funkci. Uživatel muže ˚ v programu pracovat s nˇekolika základními datovými typy – v jazyce C se jedná o typy int a float, typ k vyjádˇrení logické hodnoty je pak reprezentován typem bool, který je definován v hlaviˇckovém souboru. V dodávaných hlaviˇckových souborech je navíc možné setkat se s typy lsa_int a lsa_float, které odpovídají typum ˚ int a float. Aby uživatel pˇri implementaci dopravního algoritmu nepracoval s pojmy, které se vztahují k syntaxi jazyka C, jsou mu tyto typy zobrazeny pod názvy jako „celé cˇ íslo“ a podobnˇe. Tyto datové typy jsou pro vytváˇrení dopravního algoritmu dostaˇcující, proto nejsou žádné jiné typy k dispozici. Pˇri volbˇe návratového typu funkce je uživateli navíc nabídnut typ void, aby mohl vytváˇret funkce, které nevracejí žádnou hodnotu. Další funkcí modulu je kontrola dodržení pravidel pro pojmenovávání promˇenných v jazyce C (dovolené znaky apod.). Program také hlídá, aby nebylo možné vytvoˇrit dvˇe promˇenné se stejným jménem, a je zakázáno odstranit promˇennou, která již byla použita na nˇekterém místˇe v algoritmu. To samé platí u vytváˇrení a odstranovᡠní funkcí. Programy jsou ukládány ve formátu XML a každý soubor je zabezpeˇcen proti ruˇcní editaci mimo aplikaci (viz. kapitola 4.7). Kromˇe tvorby dopravních programu˚ musí modul umˇet generovat zdrojový soubor v jazyce C, zajistit jeho pˇreklad pro procesory architektury ARM a operaˇcní systém Linux a vytvoˇrit soubor, který bude pˇripraven k zavedení do rˇ adiˇce svˇetelné signalizace. Po vytvoˇrení zdrojového souboru je možné soubor zobrazit se zvýraznˇenými klíˇcovými slovy a po pˇrekladu je možné zobrazit také log, ve kterém jsou zvýraznˇeny pˇrípadné chyby pˇrekladu a varování. 13
3. P OPIS GRAFICKÉHO MODULU
3.3
Vývojový diagram
Pro tvorbu dopravních algoritmu˚ byl jako prostˇredek zvolen vývojový diagram. Výhodou vývojového diagramu je pˇredevším fakt, že je intuitivní a není potˇreba znát témˇerˇ žádnou syntaxi, což bylo úˇcelem modulu. Z tohoto duvodu ˚ také nebyl zvolen napˇríklad pseudokód. Aby mohl být pseudokód pˇreveden do kódu v jazyce C, musel by mít nadefinovanou pevnou strukturu, a nemˇelo by tedy význam mu dávat pˇrednost pˇred programovacím jazykem. Dopravní inženýrˇ i navíc mají cˇ asto zkušenosti s vývojovými diagramy a bˇežnˇe s nimi pracují. Každá funkce je tedy reprezentována vývojovým diagramem, ve kterém lze pracovat s nˇekolika grafickými znaˇckami. Pˇri založení funkce automaticky vznikají znaˇcky pˇredstavující zaˇcátek a konec algoritmu, které nelze odstranit. Mají tvar kruhu, obsahují popisek a vkládají se mezi nˇe další znaˇcky, které pˇredstavují jednotlivé kroky algoritmu. Symboly vývojového diagramu jsou propojeny úseˇckami se šipkou, které urˇcují smˇer zpracování algoritmu. Základní znaˇckou je symbol zpracování, ve kterém je možné volat ostatní funkce cˇ i funkce z hlaviˇckových souboru, ˚ které jsou dodávány k rˇ adiˇci, a pˇriˇrazovat hodnoty lokálním cˇ i globálním promˇenným. Pokud funkce vrací nˇejakou hodnotu, je možné volat i pˇríkaz return. Funkce pro výstup byly zcela vynechány, protože pˇri tvorbˇe dopravního rˇ ešení nejsou potˇreba. Každý symbol zpracování má tvar obdélníku a je jedním pˇríkazem jazyka C. Další grafickou znaˇckou je symbol rozhodování pˇredstavující pˇríkaz if-else. Podmínˇený výraz je znázornˇen kosoˇctvercem, který obsahuje podmínku v textové formˇe, a z tohoto kosoˇctverce pak vycházejí dvˇe vˇetve – první vˇetev pro pˇrípad, kdy je podmínka vyhodnocena jako pravdivá, druhá pro pˇrípad opaˇcný. Podmínˇený výraz je využíván také v pˇrípadˇe cyklu while. Symboly lze do vývojového diagramu pˇridávat jako následníky již existujících symbolu. ˚ U pˇríkazu if-else je také možné vkládat symboly do jednotlivých vˇetví a u cyklu while pak do jeho tˇela. Každý symbol lze z vývojového diagramu odstranit, pokud se jedná o cyklus nebo pˇríkaz if-else, jsou odstranˇeny i všechny symboly, které jsou jeho souˇcástí. Uživateli je také umožnˇeno jednotlivé symboly v rámci jednoho vývojového diagramu pˇresunovat. 14
3. P OPIS GRAFICKÉHO MODULU
3.4
Práce s pˇríkazy a podmínkami
Aby se co nejvíce zamezilo vzniku syntaktických chyb, je uživatel znaˇcnˇe omezen pˇri vkládání pˇríkazu˚ nebo podmínˇených výrazu˚ do vývojového diagramu. V symbolu zpracování je uživateli dovoleno volat funkce nebo pˇriˇrazovat výrazy do promˇenných. V pˇrípadˇe volání funkce je uživateli zobrazeno okno, ve kterém musí do funkce doplnit všechny její parametry. Na výbˇer dostává jen takové promˇenné, které odpovídají danému datovému typu. V pˇrípadˇe pˇriˇrazování hodnot do promˇenných má pak k dipozici okno, které funguje na principu klasické kalkulaˇcky s nˇekolika zmˇenami. Kromˇe možnosti zadávání cˇ ísel a tlaˇcítek pro nˇekolik jednoduchých matematických operací jsou zde tlaˇcítka pro použití jiné promˇenné, konstanty a také funkce. Pokud uživatel vybere funkci, dostane na výbˇer pouze takové, jejichž návratový typ se shoduje s datovým typem promˇenné, do které se pˇrirˇ azuje. Uživateli není dovoleno použít dva znaky pro matematické operace za sebou a pokud je po dokonˇcení výraz ukonˇcen takovým znakem, je tento znak odstranˇen. Kontroluje se také správné použití závorek. Pˇri tvorbˇe podmínˇených výrazu se uživateli obdobnˇe zobrazí okno podobné kalkulaˇcce, místo aritmetických operací jsou zde však logické spojky AND, OR, negace a relaˇcní operátory. Dochází zde také k podobné kontrole používání znaku˚ jako u pˇriˇrazování výrazu˚ do promˇenných. Kromˇe promˇenných a funkcí, které si uživatel sám zadefinuje, je možné používat dopravní funkce obsažené v hlaviˇckovém souboru, který je dodáván k rˇ adiˇci, a konstanty z hlaviˇckového souboru urˇceného pro vybranou kˇrižovatku.
15
4 Implementace V této kapitole jsou popsány hlavní body implementace celého modulu. První fází byla práce s vývojovým diagramem. Byly vytvoˇreny tˇrídy, které jsou pro vývojový diagram potˇreba, a poté metody nutné pro vkládání prvku˚ do vývojového diagramu a odebírání prvku˚ z vývojového diagramu. Následovala implementace nástroje, který je schopen vývojový diagram serializovat a deserializovat a umožnit tak jeho uložení ve formátu XML [7]. Další fází byla implementace nástroju˚ pro zpracování hlaviˇckových souboru, ˚ pro pˇrevod diagramu do zdrojového kódu v jazyce C a pro pˇreklad do objektového souboru. Poslední fází bylo vykreslování vývojového diagramu a práce s formuláˇri a ovládacími prvky Windows Forms [8].
4.1
Prostˇredky a vstupní parametry
Celý nástroj byl vyvíjen v jazyce C# v prostˇredí Microsoft Visual Studio 2013 pro operaˇcní systém Microsoft Windows. Pro spuštˇení modulu je potˇreba platforma .NET Framework 4.0 (nebo vyšší), kterou lze na operaˇcní systém Windows doinstalovat již od verze Windows XP a která je souˇcástí Windows 8. Jazyk C# byl zvolen z toho duvodu, ˚ že nástroj je modulem do již existující aplikace, která je naprogramována právˇe v tomto jazyce. Ze stejného duvodu ˚ je nutné modulu pˇredávat nˇekolik vstupních parametru. ˚ Prvním z nich je název kˇrižovatky, pro kterou bude tvorˇ en dopravní algoritmus (jen pro úˇcely zobrazení), dále cesta k hlaviˇckovému souboru s definicemi objektu˚ rˇ adiˇce SSZ dané kˇrižovatky a k hlaviˇckovému souboru s dopravními funkcemi. Ve složce definice budou po spuštˇení modulu doplnˇeny soubory: •
soubor XML, ve kterém budou uloženy definice vývojového diagramu (pokud taková definice už existuje, je použita, jinak se zakládá nová).
•
soubor libptc.c, t.j. zdrojový soubor s upravenými funkcemi preLogic(), mainLogic(), postLogic(). Do souboru bude vložen 16
4. I MPLEMENTACE hlaviˇckový soubor objektu˚ (PTC.h) i hlaviˇckový soubor dopravních funkcí. •
soubor libptc.o (kompilovaný zdrojový soubor)
4.2
Základní tˇrídy
Obrázek 4.1: Diagram tˇríd – základní tˇrídy CFile: hlavní tˇrída, která pˇredstavuje jeden soubor v jazyce C. Každý objekt této tˇrídy obsahuje seznam globálních promˇenných (objektu˚ tˇrídy Variable) a seznam funkcí (objektu˚ tˇrídy CFunction). Obsahuje metody, které urˇcují, zda je možné odstranit danou globální promˇennou cˇ i funkci (zda nejsou v dopravním programu použity). CFunction: pˇredstavuje funkci v rámci jednoho souboru v jazyce C, obsahuje seznam lokálních promˇenných, seznam vstupních parametru, ˚ metodu, která urˇcí, zda lze odstranit danou lokální promˇennou (zda není použita) a metodu pro pˇrevod do kódu v jazyce C. Variable: tˇrída pro vyjádˇrení promˇenné s jejím datovým typem, názvem a hodnotou. Každou promˇennou lze vyjádˇrit pomocí kódu v jazyce C. 17
4. I MPLEMENTACE DataTypes: výˇcet všech typu, ˚ které lze v dopravním programu použít. Jsou také implementovány metody, které tyto typy pˇrevádˇejí na text cˇ itelný pro dopravního inženýra. Tˇrídy pˇredstavující jednotlivé symboly vývojového diagramu (obrázek 4.2):
Obrázek 4.2: Diagram tˇríd – tˇrídy vývojového diagramu Flowchart: pˇredstavuje vývojový diagram, každá funkce má právˇe jeden. Uchovává seznam všech symbolu˚ použitých v diagra18
4. I MPLEMENTACE mu. Obsahuje metody pro vložení a odebrání symbolu, ˚ metodu pro posun symbolu˚ v matici v rámci rˇ ádku, ˚ metodu pro kontrolu, zda jsou vyplnˇeny všechny podmínky v rozhodovacích symbolech, aby bylo možné vytvoˇrit zdrojový kód, a metodu, která zjistí, jestli všechny funkce (kromˇe tˇech, které nevrací žádnou hodnotu) obsahují pˇríkaz return. ComponentRelation: tˇrída k vyjádˇrení vztahu mezi dvˇema komponentami. Slouží hlavnˇe k vykreslování spojnic mezi symboly a pro pˇresun symbolu. ˚ FlowchartRenderer: statická tˇrída sloužící k vykreslování vývojového diagramu. FlowchartController: zprostˇredkovává spojení vývojového diagramu s panelem, na který je diagram vykreslován. Umožnuje ˇ pak pracovat s diagramem pomocí myši – pˇresunovat symboly v rámci diagramu. FlowchartComponent: abstraktní tˇrída, pˇredstavuje jeden symbol vývojového diagramu. Každý symbol má metodu ToCode() pro pˇrevod do kódu v jazyce C a ukazuje na symbol, který ve vývojovém diagramu následuje. Uchovává si svou pozici ve dvourozmˇerné matici pomocí vlastností Row a Column. BeginComponent: pˇredstavuje poˇcáteˇcní symbol vývojového diagramu, kromˇe pˇrevodu do kódu v jazyce C nemá žádné metody. EndComponent: koncový symbol vývojového diagramu, kromˇe pˇrevodu do kódu v jazyce C nemá žádné metody. RectangleComponent: zastupuje symbol zpracování, lze v nˇem pˇrirˇ adit hodnotu promˇenné a volat funkce a pˇríkaz return. IfComponent: pˇredstavuje pˇríkaz if-else, uchovává si seznam symbolu˚ obsažených v obou vˇetvích a použitou podmínku. Obsahuje metody pro pˇridání symbolu˚ do jednotlivých vˇetví, odebrání symbolu˚ z jednotlivých vˇetví a pro pˇrepoˇcítávání pozice symbolu˚ ve vˇetvích pˇríkazu. 19
4. I MPLEMENTACE WhileComponent: while cyklus, uchovává si seznam symbolu˚ vyskytujících se v tˇele cyklu a použitou podmínku. Obsahuje metody pro vložení/odstranˇení symbolu do/z cyklu a pro pˇrepocˇ ítávání pozice symbolu˚ obsažených v cyklu.
4.3
Grafická reprezentace vývojového diagramu
Každý symbol je tvoˇren jednoduchým geometrickým útvarem, uvnitˇr kterého je text. Tento útvar je vykreslen na souˇradnice urˇcené jeho pozicí v matici – vlastnostmi Row a Column. Pro vykreslování vývojového diagramu slouží statická tˇrída FlowchartRenderer. Tato tˇrída zprostˇredkuje vykreslení daného symbolu na panel pomocí metody DrawPath(GraphicsPath), jejímž vstupním parametrem je objekt tˇrídy GraphicsPath. Právˇe tato tˇrída byla použita jako rˇ ešení grafické reprezentace symbolu˚ – každý prvek vývojového diagramu je tedy reprezentován objektem této tˇrídy. Díky tomu lze v jakýkoliv moment zjistit, zda se nachází ukazatel myši uvnitˇr nˇejakého symbolu a implementovat tak metody pro stisknutí tlaˇcítka myši. Po vykreslení každého symbolu je volána metoda ResizeCanvas(Panel, GraphicsPath), která kontroluje, zda se objekt nevykresluje mimo hranice panelu. V pˇrípadˇe pˇresáhnutí hranic pak tento panel zvˇetší o potˇrebné množství obrazových bodu. ˚ Pˇri najetí myší na symbol je symbol pro odlišení od ostatních barevnˇe zvýraznˇen. Zvýraznˇení je implementováno pomocí metody GetBounds(), kterou poskytuje tˇrída GraphicsPath, a pomocí aktuálních souˇradnic ukazatele myši. V okamžiku, kdy se ukazatel vyskytuje uvnitˇr symbolu (zjišt’ováno pomocí metody IsVisible(Point) tˇrídy GraphicsPath), je symbol oznaˇcen jako „vybraný“ a pˇri vykreslování dojde také k vybarvení oblasti získané metodou GetBounds().
4.4
Tvorba vývojového diagramu
Tvorba vývojového diagramu je rˇ ešena pomocí dvourozmˇerné matice, kde každý symbol je umístˇen v bunce ˇ urˇcitého rˇ ádku a sloupce. Tento zpusob ˚ byl zvolen hlavnˇe kvuli ˚ vykreslování, pro samotný objekt vývojového diagramu tento zpusob ˚ nemá žádný význam, proto20
4. I MPLEMENTACE že jednotlivé symboly jsou na sebe navázány v podobˇe zˇretˇezeného seznamu (každý symbol si uchovává svého následníka). Pˇri vkládání symbolu˚ do diagramu je nutné dva po sobˇe jdoucí symboly „rozpojit“ a vložit mezi nˇe nový symbol. Zanikne tedy jedno spojení mezi symboly a vznikají dvˇe spojení nová. Jsou také aktualizováni následníci tˇechto symbolu. ˚ Všechny symboly vyskytující se na rˇ ádku vˇetším než je rˇ ádek novˇe vloženého symbolu jsou posunuty o takový poˇcet rˇ ádku˚ níže, kolik jich nový symbol zabírá. Pˇri odebírání symbolu˚ je použit opaˇcný postup. Dvˇe spojení zaniknou a vzniká jedno nové mezi pˇredcházejícím a následujícím symbolem odebíraného symbolu. Opˇet dojde k posunutí symbolu, ˚ které se nacházejí na rˇ ádcích vˇetších než byl rˇ ádek odebíraného symbolu, tentokrát smˇerem nahoru.
Obrázek 4.3: Vývojový diagram Ke komplikaci muže ˚ dojít až v pˇrípadˇe, nachází-li se pˇridávaný nebo odebíraný symbol uvnitˇr pˇríkazu if-else. Nˇekdy totiž musí dojít k posunu nejen v rámci rˇ ádku, ˚ ale i sloupcu, ˚ napˇríklad pokud máme vývojový diagram na obrázku 4.3 a odstraníme druhý pˇríkaz if-else z pravdivé vˇetve prvního pˇríkazu if-else, je symbol pˇriˇrazení z nepravdivé vˇetve prvního pˇríkazu if-else posunut o jeden sloupec do21
4. I MPLEMENTACE leva. Tento problém rˇ eší metoda, která nejdˇríve zjistí, zda je vubec ˚ posun potˇreba. Po provedení posunu je tato metoda volána pro rodiˇcovský symbol (pokud existuje). Tato situace by nastala napˇríklad v pˇrípadˇe, kdyby první pˇríkaz if-else z obrázku 4.3 ležel uvnitˇr pravdivé vˇetve dalšího pˇríkazu if-else. V ten okamžik by bylo potˇreba provést posun v rámci sloupcu˚ i na vyšší úrovni. Stejný postup je použit i pˇri posunu rˇ ádku, ˚ který je nutné provést i na vyšších úrovních. Díky reprezentaci symbolu˚ pomocí tˇrídy GraphicsPath lze jednotlivé symboly v rámci jednoho vývojového diagramu také pˇremíst’ovat. Stisknutím tlaˇcítka myši, když je kurzor umístˇen na symbolu, je symbol vybrán (pomocí metody IsVisible(Point)) a barevnˇe zvýraznˇen. Poté uživatel vybere spojnici, na kterou chce zvolený symbol pˇresunout. V dobˇe mezi výbˇerem symbolu a spojnice je vývojový diagram pˇrepnut do stavu „pˇremíst’ování“ a spojnice, na které je možné vybraný symbol pˇresunout, jsou pˇri pˇrejetí myší barevnˇe zvýraznovány. ˇ Po stisknutí tlaˇcítka myši, když je kurzor umístˇen na spojnici, dojde k odstranˇení symbolu z jeho aktuální pozice a k vložení na pozici novou. Pokud uživatel stiskne tlaˇcítko myši, když je kurzor mimo barevnˇe vyznaˇcenou spojnici, pˇrepne se vývojový diagram zpˇet do bˇežného stavu a k pˇresunu nedojde. Lze pˇremíst’ovat i celé bloky symbolu, ˚ napˇríklad pˇri výbˇeru symbolu pro pˇríkaz ifelse se pˇresunou i všechny symboly, které se uvnitˇr tohoto pˇríkazu nacházejí.
4.5
Výrazy a podmínky
Výrazy a podmínky použité v programu jsou uchovávány jako seznamy objektu˚ tˇríd, které implementují rozhraní IExpression. Napˇríklad výraz radek + (77 − sloupec) bude reprezentován jako seznam prvku˚ radek, +, (, 77, −, sloupec, ). Tento zpusob ˚ byl zvolen z duvodu ˚ jednoduché orientace mezi jednotlivými cˇ ástmi výrazu, která je du˚ ležitá napˇríklad pˇri kontrole, zda daná promˇenná nebo funkce není použita v nˇekterém z výrazu. ˚ Staˇcí tak pouze projít seznam a zjistit, jestli kontrolovanou promˇennou nebo funkci obsahuje. Tento zpusob ˚ uložení výrazu˚ a podmínek, které uživatel sestavil, umožnuje ˇ také kontrolu správnosti, která je rˇ ešena pomocí statické tˇrídy ExpressionChecker. Tato tˇrída poskytuje kontrolu závorek v da22
4. I MPLEMENTACE ném výrazu nebo podmínce – kontroluje, jestli ke každé levé závorce existuje i pravá závorka. Kontrola závorek však není dostaˇcující, a tak jsou implementovány metody pro dukladnˇ ˚ ejší kontrolu. Kontrola výrazu˚ probíhá podle formální gramatiky vyjádˇrené v BNF [9] (Backusova-Naurova forma):
hvyrazi ::= cislo | volani_funkce | promenna | konstanta hvyrazi ::= hvyrazi hoperatori hvyrazi hvyrazi ::= ‘(’ hvyrazi ‘)’ hoperatori ::= ‘+’ | ‘-’ | ‘*’ | ‘/’ Podmínky jsou kontrolovány podle obdobné gramatiky, ve které pˇribude pravidlo pro negaci:
hvyrazi ::= ‘!’ hvyrazi a pravidlo
hoperatori ::= ‘+’ | ‘-’ | ‘*’ | ‘/’ je nahrazeno pravidlem:
hoperatori ::= ‘&&’ | ‘||’ | ‘==’ | ‘>’ | ‘<’| ‘>=’| ‘<=’| ‘!=’ Podle tˇechto gramatik je sestaven algoritmus, který zabrání používání nesprávnˇe vytvoˇrených výrazu˚ a podmínek, které by zpu˚ sobily problémy pˇri pˇrekladu.
4.6
Ukládání a naˇcítání vytvoˇrených programu˚
Modul umí vytvoˇrený program pro danou kˇrižovatku uložit pro pozdˇejší použití ve formátu XML a pˇri dalším otevˇrením modulu jej pro tutéž kˇrižovatku znovu naˇcíst. Serializace dopravního programu byla rˇ ešena dvˇema zpusoby. ˚ Nejprve bylo použito rˇ ešení pomocí tˇrídy XmlSerializer, díky které lze serializovat a deserializovat objekty velmi jednoduchým zpu˚ sobem. Nevýhodou tˇrídy XmlSerializer napˇríklad oproti tˇrídám BinaryFromatter nebo SoapFormatter (které se také k serializaci používají) je fakt, že lze serializovat pouze její veˇrejné vlastnosti, pro úˇcely 23
4. I MPLEMENTACE serializace programu to však staˇcilo. Navíc na rozdíl od tˇrídy BinaryFormatter také podporuje serializaci generických kolekcí, což bylo u ukládání vytvoˇrených programu˚ nutností. Aˇckoli XmlSerializer poskytuje programátorovi dost velkou kontrolu nad serializací a deserializací, u nˇekterých složitˇejších objektu˚ bylo nutné proces kontrolovat dukladnˇ ˚ eji. Toho bylo dosaženo implementací rozhraní IXmlSerializable. V metodách WriteXml(XmlWriter) a ReadXml(XmlReader) pak lze podrobnˇeji popsat, jak se má tˇrída serializovat a deserializovat. Tento zpusob ˚ byl však kvuli ˚ velkému množství složitých objektu˚ pˇríliš komplikovaný, a tak bylo nakonec zvoleno rˇ ešení pomocí tˇrídy XamlServices. Tˇrída XamlServices poskytuje metodu Save(Stream, Object), která umožnuje ˇ pˇrevést objekt na textovou reprezentaci ve znaˇckovacím jazyce XAML, který je založen na jazyce XML. Tato tˇrída si umí automaticky poradit jak se serializací generických kolekcí, tak i se složitými objekty. Metoda Load(Stream) pak zajistí deserializaci. Koˇrenovým elementem XML souboru je element CFile pˇredstavující stejnojmennou tˇrídu (všechny názvy elementu˚ odpovídají názvum ˚ tˇríd, které pˇredstavují). Do tohoto elementu je po vytvoˇrení souboru vložen haš, který zabrání naˇcítání poškozených souboru. ˚ Dceˇrinné elementy pˇredstavují jednotlivé funkce, které program obsahuje, a seznam serializovaných globálních promˇenných. Každý element pˇredstavující funkci pak obsahuje serializovaný seznam lokálních promˇenných a vývojový diagram. Vývojový diagram je reprezentován jako elementy, které pˇredstavují jednotlivé symboly diagramu. Každý takový element má v atributech uvedený sloupec a rˇ ádek, ve kterém se nachází, a také pocˇ et sloupcu˚ a rˇ ádku, ˚ které v poli zabírá. Rozhodovací symboly mají navíc atribut pro uložení podmínky. Element symbolu zpracování obsahuje jeden dceˇrinný element, ve kterém jsou uloženy informace o pˇríkazu použitém v tomto symbolu. Ostatní vlastnosti byly vynechány nastavením atributu DesignerSerializationVisibility na hodnotu Hidden, protože je nebylo potˇreba zachovávat. Proces deserializace je o nˇeco složitˇejší než proces serializace z toho duvodu, ˚ že nˇekteré informace je zbyteˇcné ukládat do souboru XML, a je tedy nutné je pozdˇeji obnovit. Každému symbolu musí být znovu pˇriˇrazen ovládací prvek, na který se bude symbol vykreslovat. Dále je nutné obnovit vztahy mezi symboly, toho je docíleno 24
4. I MPLEMENTACE pomocí atributu Row – symbol ve vývojovém diagramu vždy navazuje na symbol na pˇredchozím rˇ ádku. Projde se tedy seznam symbolu, ˚ pomocí vlastnosti NextComponent se propojí a na závˇer se vytvoˇrí všechny odpovídající objekty tˇrídy ComponentRelation.
4.7
Zabezpeˇcení souboru XML
Pˇri deserializaci programu˚ ze souboru XML bylo potˇreba zajistit, aby nedošlo k naˇctení ruˇcnˇe pozmˇenˇeného souboru. Serializovaná data jsou velmi citlivá na svou integritu, a tu prostý XML soubor nezaruˇcuje. I málo zkušení uživatelé znají možnost zasáhnout do souboru XML pomocí textového editoru a toho také nˇekdy využívají jako rychlé možnosti úpravy informací bez nutnosti spouštˇet aplikaci k provedení zmˇen. Takové úpravy však nˇekdy konˇcí poškozením dat, které pak již aplikace není schopna zpracovat. Požadavkem proto bylo i rˇ ešení tohoto problému. K vyˇrešení byl zvolen jednoduchý postup – odmítnutí jakéhokoliv souboru, který byl upraven mimo vlastní grafický modul pro tvorbu vývojových diagramu. ˚ Toho bylo docíleno tak, že pˇri ukládání dat do souboru je vypoˇcten hašovací funkcí otisk (haš) celé datové cˇ ásti souboru a ten je do vytvoˇreného XML souboru pˇridán do koˇrenového elementu jako atribut. Pˇri naˇcítání dat ze souboru je postup stejný, opˇet je haš spoˇcítán a porovnán s uloženým. V pˇrípadˇe nerovnosti dojde k odmítnutí naˇctení souboru. Jako hašovací funkce byl použit algoritmus MD5 [10] (MessageDigest Algorithm). Tento algoritmus je jedna z bˇežných hašovacích funkcí a je velmi snadno dostupný v prostˇredí Microsoft .NET Framework. Nebyl provádˇen žádný další výbˇer na základˇe kryptografických vlastností (prolomitelnost apod.), vzhledem k tomu, že to daný úˇcel nevyžaduje. Doba výpoˇctu této hašovací funkce je i pro velmi velké XML soubory zcela zanedbatelná.
4.8
Syntaktická analýza hlaviˇckových souboru˚
Souˇcástí modulu je statická tˇrída FileParser pro syntaktickou analýzu hlaviˇckových souboru˚ s deklaracemi dopravních funkcí a souboru˚ s definicemi konstant. Tˇrída zpracovává takové informace o tˇech25
4. I MPLEMENTACE to funkcích, aby je bylo pozdˇeji možné volat pˇri tvorbˇe vývojových diagramu. ˚ Dodávané hlaviˇckové soubory obsahují také kompletní dokumentaci, která se rovnˇež ukládá, aby dopravní inženýr mohl pozdˇeji funkce pohodlnˇe použít. Pˇri zpracování dokumentace analyzátor vyhledává poˇcáteˇcní znak „/**“. Do té doby komentáˇre zaˇcínající znaky „//“ nebo „/*“ vynechává. Jakmile narazí na poˇcáteˇcní znak dokumentace, naˇcte popis funkce a hledá znaˇcky pro popis parametru˚ (@param) a pro popis návratové hodnoty (@return). Ostatní znaˇcky ignoruje, protože nejsou pro pozdˇejší použití podstatné. Pokud k funkci není k dispozici dokumentace, zpracuje analyzátor funkci bez ní. Po naˇctení dokumentace oˇcekává analyzátor deklaraci funkce ve tvaru návratový_typ název_funkce(datový_typ1 parametr1, datový_typ2 parametr2, ...). Pˇred znakem levé závorky hledá název funkce, pˇred názvem funkce návratový typ. V okamžiku, kdy narazí na závorku, zaˇcne zpracovávat parametry funkce, které od sebe rozpozná, protože jsou od sebe standardnˇe oddˇeleny cˇ árkou.
Obrázek 4.4: Diagram tˇríd – analyzátor hlaviˇckových souboru˚
26
4. I MPLEMENTACE Analyzátor pracuje s tˇemito tˇrídami (obrázek 4.4): HeaderFile: pˇredstavuje celý hlaviˇckový soubor, obsahuje seznam funkcí v nˇem obsažených Function: tˇrída pro uchování funkce (návratový typ, název, seznam parametru) ˚ naˇctené z hlaviˇckového souboru a její dokumentace (popis funkce, popis parametru, ˚ popis návratové hodnoty) Parameter: pˇredstavuje vstupní parametr funkce, který má svuj ˚ název, datový typ a popis Další soubory, které jé nutné zpracovat, jsou hlaviˇckové soubory s definicemi objektu˚ rˇ adiˇce SSZ (jedná se o konstanty rozdˇelené do skupin). Je potˇreba ukládat jak názvy konstant a jejich hodnoty, tak názvy skupin. Analyzátor tedy nejprve hledá komentáˇr, ze kterého naˇcte název skupiny, poté hledá rˇ ádky obsahující klíˇcové slovo #define a z nich naˇcte jméno a hodnotu konstanty. Soubor je generován automaticky, proto je formát vždy stejný – komentáˇr s názvem skupiny následovaný pˇríslušnými konstantami, napˇríklad: /* Sections */ # define Krizovatka 0 # define Prechod 1 / * Plans * / # define P1_70_D_K # define P2_70_D_K # define P3_75_D_K # define P4_75_D_K # define P5_93_D_K # define P6_93_D_K
0 1 2 3 4 5
27
4. I MPLEMENTACE
4.9
Generování zdrojového kódu
Soubor obsahující kód v jazyce C se generuje následujícím zpusobem ˚ pomocí statické tˇrídy FlowchartConvertor a její metody ConvertToCode(CFile, String): Jako první se do souboru zapíší direktivy #include s potˇrebnými hlaviˇckovými soubory. Následují deklarace všech globálních promˇenných a funkcí. Poté jsou postupnˇe zapsány definice funkcí. Nejdˇríve je vytvoˇrena hlaviˇcka funkce tak, aby odpovídala zápisu v jazyce C, poté je nutné zpracovat vývojový diagram. Zaˇcíná se u symbolu pro zaˇcátek algoritmu, který se do souboru zapíše jako znak levé složené závorky. Je nutné nejprve deklarovat všechny lokální promˇenné a až poté postupnˇe procházet následníky symbolu pro zaˇcátek algoritmu. Zpracování následníku˚ probíhá podle jednoduchých pravidel: pokud se jedná o symbol zpracování, získá se kód, který tento symbol obsahuje a je doplnˇen o stˇredník. Pokud se jedná o symbol rozhodování, zapíše se if (v pˇrípadˇe cyklu pak while) a do závorek podmínka, poté jsou zpracovány symboly v jednotlivých vˇetvích (nebo v tˇele cyklu). V okamžiku, kdy se narazí na symbol konce algoritmu, je doplnˇena pravá složená závorka a dojde k zapsání další funkce.
4.10 Pˇreklad Pˇreklad vygenerovaného zdrojového souboru v jazyce C do objektového kódu .o je provádˇen pomocí standardního pˇrekladaˇce GCC, vytvoˇreného v rámci projektu GNU1 . Výbˇer konkrétní verze pˇrekladaˇce byl nakonec zúžen dvˇema základními podmínkami: •
musí být použita verze 3.3.4, protože ta je dlouhodobˇe užívána a otestována v prostˇredí rˇ adiˇce svˇetelné signalizace
•
musí se jednat o kˇrížový pˇrekladaˇc – pˇrekladaˇc, který se spouští v prostˇredí Microsoft Windows na procesorech rˇ ady x86 a výsledný kód je urˇcen pro zcela jiný procesor rˇ ady ARM
1.
https://gcc.gnu.org/
28
4. I MPLEMENTACE Na doporuˇcení dodavatele modulu˚ pro rˇ adiˇc SSZ byl použit pˇrekladaˇc GCC od Technologic Systems2 , obsahující nˇekteré moduly pro konkrétní používaný hardware. Jedná se o pˇrekladaˇc pracující pod operaˇcním systémem Linux. Jeho spouštˇení pod systémem Microsoft Windows bylo vyˇrešeno použitím nástroje Cygwin, který pod operaˇcním systémem Windows umožnuje ˇ bˇeh nˇekterých programu˚ urˇcených pro Linux. K vlastnímu pˇrekladu zdrojového souboru bylo nutné modul doplnit o: •
složku s nástrojem Cygwin
•
složku s pˇrekladaˇcem GCC
•
složku include, obsahující hlaviˇckový soubor dopravních funkcí (pˇrípadnˇe s dalšími navázanými soubory)
•
skript pro pˇreklad prepare.sh, kterému se jako parametr pˇredá cesta ke složce se zdrojovým souborem
•
konfiguraˇcní soubor Makefile3 , obsahující pˇríkazy a konfigurace pro provedení vlastního pˇrekladu
Pro zjednodušení bylo celé rˇ ešení pˇripraveno tak, aby nebylo nutné provádˇet instalaci nebo nastavování cest. Jako výchozí adresáˇr byl zvolen adresáˇr, z nˇehož se modul pro tvorbu vývojových diagramu˚ spouští, a pˇrímo do nˇej se umístí skript, konfiguraˇcní soubor a adresáˇre s nástrojem Cygwin a pˇrekladaˇcem. Konfiguraˇcním souborem je pak zajištˇen pˇreklad zdrojového souboru, cesta k nˇemu je pˇredána jako parametr. Vzniklý soubor s objektovým kódem se uloží do adresáˇre se zdrojovým souborem a v tomto adresáˇri je také vytvorˇ en záznam o pˇrekladu do souboru compile.log. Výsledný objektový soubor je komprimován do formátu .tgz a tím je kompletnˇe dokoncˇ ena pˇríprava k pˇresunu do rˇ adiˇce SSZ. Pˇreklad uživatel spouští volbou z menu, souˇcasnˇe se provede vytvoˇrení zdrojového souboru aktuálního dopravního programu. Jako výsledek se po provedení pˇrekladu zobrazí výpis obsahu souboru compile.log se zvýraznˇením pˇrípadných chybových hlášení. 2. https://www.embeddedarm.com/ 3. Soubor a skript byly pˇrevzaty z aplikace CROSS-PTC, autor: Ing. Marek Zukal.
29
5 Závˇer Cílem této bakaláˇrské práce byla implementace modulu do aplikace pro návrh dopravních rˇ ešení. Modul mˇel umožnit dopravnímu inženýrovi tvorbu dopravních algoritmu˚ pomocí vývojových diagramu˚ tak, aby pˇri této práci nebyl potˇreba programátor. Modul byl prakticky otestován ve spolupráci s dopravním inženýrem. Bylo vytvoˇreno nˇekolik jednoduchých dopravních rˇ ešení, napˇríklad pˇrechod pro chodce (ukázka v pˇríloze A) cˇ i jednoduchá kˇrižovatka. Testováním se také ukázaly další možné úpravy modulu. Byla pˇridána možnost pˇremíst’ovat symboly v rámci jednoho vývojového diagramu a v budoucnosti je plánováno umožnit psaní komentáˇru˚ a vytváˇrení dokumentace k jednotlivým funkcím. Modul nyní odpovídá všem požadavkum ˚ kladeným zadavatelem, cˇ ímž je cíl práce splnˇen. Pro dopravní inženýry by tento modul mohl být velkým pˇrínosem, jelikož jim dává možnost tvoˇrit dopravní rˇ ešení samostatnˇe a navíc zpusobem, ˚ který bˇežnˇe v praxi používají. Místo nákresu vývojových diagramu˚ na papír a jejich následného pˇrepisování do programovacího jazyka mohou diagram poskládat pomocí modulu, nechat si jej automaticky pˇrevést na zdrojový kód a pˇreložit do objektového kódu, který je zavádˇen pˇrímo do rˇ adiˇce SSZ.
30
Literatura ˇ [1] DORNÁK, David. Svˇetelné signalizaˇcní zaˇrízení s využitím technologií CROSS Zlín [PDF]. Zlín: CROSS Zlín a.s., 2. dubna 2009 [cit. 14. dubna 2015]. [2] ARM Ltd.. Cortex-A5 Processor [online] [cit. 14. dubna 2015]. Dostupné z URL: http://www.arm.com/products/processors/
cortex-a/cortex-a5.php#
[3] ISO 11898-1 Road vehicles – Controller area network (CAN) – Part 1: Data link layer and physical signaling. 2003. [cit. 14. dubna 2015]. [4] SOLTERO, Manny; ZHANG, Jing; COCKRI, Chris. RS-422 and RS-485 Standards Overview and System Configurations [online]. 2002. [cit. 14. dubna 2015]. Dostupné z URL: http://www.ti.com/
lit/an/slla070d/slla070d.pdf
[5] International Electrotechnical Comission. Functional Safety and IEC 61508 [online] [cit. 14. dubna 2015]. Dostupné z URL: http:
//www.iec.ch/functionalsafety/
[6] IERUSALIMSCHY, Roberto; FIGUEIREDO, Luiz Henrique; FILHO, Waldemar Celes. Lua – an extensible extension language [online]. 1996. [cit. 14. dubna 2015]. Dostupné z URL: http://
citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.45.2941
[7] The World Wide Web Consortium. Extensible Markup Language (XML) 1.0. Fifth Edition. [online]. 26. listopadu 2008 [cit. 14. dubna 2015]. Dostupné z URL: http://www.w3.org/TR/REC-xml/ [8] Windows Forms [online] [cit. 14. dubna 2015]. Dostupné z URL: https://msdn.microsoft.com/en-us/library/dd30h2yb(v=
vs.110).aspx
[9] GARSOL, Lars Marius. BNF and EBNF: What are they and how do they work?. [online]. 22. srpna 2008 [cit. 14. dubna 2015]. Dostupné z URL: http://www.garshol.priv.no/download/text/bnf.html 31
LITERATURA [10] RIVEST, Ronald L.. MD5 Message-Digest Algorithm. [online]. Duben 1992 [cit. 14. dubna 2015]. Dostupné z URL: http://www.
rfc-editor.org/rfc/pdfrfc/rfc1321.txt.pdf
[11] SKEET, Jon. C# in depth. 2nd ed. Stamford: Manning, 2011. xxx, 554 s. ISBN 9781935182474. [cit. 14. dubna 2015]. [12] KERNIGHAN, Brian W. a Dennis M. RITCHIE. Programovací jazyk C : The C Programming Language (Orig.). Translated by Vladimír Benko. 1. vyd. Bratislava, Praha: Alfa, Státní nakladatelství technické literatury, 1988. 249 s. [cit. 14. dubna 2015].
32
A Ukázka navrženého dopravního rˇešení Ukázka dopravního rˇ ešení navrženého pomocí modulu – pˇrechod pro chodce na ulici Husitská v Kunovicích (vývojový diagram ve formátu XML a hlaviˇckový soubor s dopravními funkcemi k tomuto rˇ ešení je pˇriložen v archivu prechod_husitska.zip.): Výsledný zdrojový kód (komentáˇre byly doplnˇeny ruˇcnˇe pro pochopení zdrojového kódu): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
# include "PTC . h " # include " o m t c I t f . h " / / G l o b a l n i promenne i n t DFAZE1 ; i n t DFAZE2 ; / / Deklarace funkci void preLogic ( ) ; void mainLogic ( ) ; void p o s t L o g i c ( ) ; bool FAZE1 ( ) ; bool FAZE2 ( ) ; /* * * Nastaveni delky f a z i . * faze 1 − vozidla * faze 2 − chodci */ void preLogic ( ) { / / N a s t a v 40 s e k u n d p r o doby t r v a n i f a z e s vozidly . DFAZE1 = 4 0 ; / / N a s t a v 20 s e k u n d p r o doby t r v a n i f a z e c h o d c u . DFAZE2 = 2 0 ; }
33
ˇ A. U KÁZKA NAVRŽENÉHO DOPRAVNÍHO REŠENÍ
28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
/* * * Vyhodnoceni p o k r a c o v a n i f a z i . */ void mainLogic ( ) { / / J e f a z e 1? i f ( PhaGet ( 1 ) ) { / / Ma f a z e 1 p o k r a c o v a t ? i f ( FAZE1 ( ) ) { / / Faze 1 p o k r a c u j e . } else { / / Nastav f a z i 2 . PhaSet ( 2 , 1 ) ; } } / / Neni f a z e 1 . else { / / Ma f a z e 2 p o k r a c o v a t ? i f ( FAZE2 ( ) ) { / / Faze 2 p o k r a c u j e . } else { / / Nastavi se f a z e 1. PhaSet ( 1 , 1 ) ; } } } void p o s t L o g i c ( ) { } /* * * Vyhodnoceni f a z e v o z i d e l . * @ r e t u r n 1= f a z e 1 ma p o k r a c o v a t , 0= f a z e 1 nema pokracovat
34
ˇ A. U KÁZKA NAVRŽENÉHO DOPRAVNÍHO REŠENÍ
64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98
*/ bool FAZE1 ( ) { / / Doba t r v a n i f a z e j e m e n s i n e z n a s t a v e n a d o b a . i f ( PhaDauer ( 1 )
35
ˇ A. U KÁZKA NAVRŽENÉHO DOPRAVNÍHO REŠENÍ
Vývojové diagramy:
Obrázek A.1: Vývojový diagram funkce preLogic()
36
Obrázek A.2: Vývojový diagram funkce mainLogic()
ˇ A. U KÁZKA NAVRŽENÉHO DOPRAVNÍHO REŠENÍ
37
ˇ A. U KÁZKA NAVRŽENÉHO DOPRAVNÍHO REŠENÍ
Obrázek A.3: Vývojový diagram funkce FAZE1()
38
ˇ A. U KÁZKA NAVRŽENÉHO DOPRAVNÍHO REŠENÍ
Obrázek A.4: Vývojový diagram funkce FAZE2()
39
B Úpravy pro bakaláˇrskou práci a instalace Protože jsou modulu pˇredávány vstupní parametry z aplikace CROSS-PTC, bylo nutné modul pro prezentaci bakaláˇrské práce mírnˇe upravit: Cesta ke všem potˇrebným souborum ˚ a nástrojum ˚ je nastavena na adresáˇr, ze kterého je modul spouštˇen. Aby bylo možné ukázat použití dopravních funkcí a objektu˚ z hlaviˇckových souboru, ˚ jsou pˇriloženy vzorové soubory libptc.h, omtcItf.h a omtcBas.h. V záhlaví hlavního formuláˇre má být název kˇrižovatky, pro kterou je rˇ ešení navrhováno. Pro demonstraˇcní úˇcely je tento text nastaven na „Husitská - pˇrechod, Kunovice“. Pokyny pro instalaci: •
Pro spuštˇení modulu je potˇreba .NET Framework 4.0 nebo vyšší.
•
Všechny soubory a adresáˇre z archivu PTCModul.zip je nutné umístit do jednoho adresáˇre. Cesta k adresáˇri nesmí obsahovat diakritiku nebo mezery. Vybraný adresáˇr by tedy mˇel obsahovat adresáˇre arm-gcc-3.3.4 a Cygwin, soubory Makefile, prepare.sh, omtcItf.h, omtcBas.h a PTC.h a spustitelný soubor PtcModul.exe.
•
Soubor PtcModul.exe spustí modul.
40
C Elektronické pˇrílohy •
text bakaláˇrské práce ve formátu PDF
•
archiv se zdrojovými soubory
•
archiv PTCModul.zip se spustitelným souborem, nástrojem Cygwin, pˇrekladaˇcem GCC, soubory potˇrebnými pro pˇreklad vytvoˇrených programu˚ a vzorovými hlaviˇckovými soubory
•
manuál k modulu ve formátu PDF
•
archiv prechod_husitska.zip se soubory k ukázce navrženého dopravního rˇ ešení
41
