Simulator of Railway Interlocking

(1)

VYSOK ´

E U ˇ

CEN´I TECHNICK ´

E V BRN ˇ

E

BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV INTELIGENTN´ICH SYST ´

EM ˚

U

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INTELLIGENT SYSTEMS

SIMUL ´

ATOR ˇ

ZELEZNI ˇ

CN´IHO STAV ˇ

EDLA

BAKAL ´

A ˇ

RSK ´

A PR ´

ACE

BACHELOR’S THESIS

AUTOR PR ´

ACE

BED ˇ

RICH HOVORKA

AUTHOR

(2)

FAKULTA INFORMA ˇ

CN´ICH TECHNOLOGI´I

´

USTAV INTELIGENTN´ICH SYST ´

EM ˚

U

FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INTELLIGENT SYSTEMS

SIMUL ´

ATOR ˇ

ZELEZNI ˇ

CN´IHO STAV ˇ

EDLA

SIMULATOR OF RAILWAY INTERLOCKING

BAKAL ´

A ˇ

RSK ´

A PR ´

ACE

BACHELOR’S THESIS

AUTOR PR ´

ACE

BED ˇ

RICH HOVORKA

AUTHOR

VEDOUC´I PR ´

ACE

Ing. DAVID MARTINEK

SUPERVISOR

(3)

Zad´

an´ı

1. Prostudujte funkce a souˇcásti elektronického ˇzelezniˇcn´ıho stavˇedla pouˇz´ıvaného pro ˇr´ızen´ı provozu v ˇzelezniˇcn´ıch stanic´ıch.

2. Prostudujte simulaˇcn´ı metody pouˇzitelné pro realizaci simulátoru ˇzelezniˇcn´ı s´ıtˇe v ˇ ze-lezniˇcn´ı stanici, zejména diskrétn´ı, spojitou a kombinovanou simulaci. Navrhnˇete vhodný simulaˇcn´ı pˇr´ıstup, ˇci kombinaci pˇr´ıstup˚u pro realizaci tohoto simulátoru. Na-vrhnˇete vhodný formát dat pro reprezentaci modelu ˇzelezniˇcn´ı s´ıtˇe.

3. Navrhnˇete a implementujte vybranou ˇcást simulátoru a demonstrujte funkˇcnost na dostateˇcnˇe názorném modelu.

4. Diskutujte z´ıskané výsledky a dalˇs´ı moˇzné smˇery vývoje.

Kategorie: Modelov´an´ı a simulace

Implementaˇcn´ı jazyk: Java, nebo podle vlastn´ıho uv´aˇzen´ı

Operaˇcn´ı syst´em: Windows, Linux

Literatura: Podle pokyn˚u vedouc´ıho

Datum zad´an´ı: 1. listopadu 2006

(4)

Licenˇcn´ı smlouva je uloˇzena v archivu Fakulty informaˇcn´ıch technologi´ı Vysok´eho uˇcen´ı technick´eho v Brnˇe.

(5)

Abstrakt

Stavˇedlo je dispeˇcerské zaˇr´ızen´ı pro ˇr´ızen´ı dopravy. Dispeˇcer urˇcuje nastavován´ım výhybek a semafor˚u cestu vlak˚um. V této práci se zabývám návrhem a výstavbou základu simulátoru takového zaˇr´ızen´ı v jazyce Java. Nastudoval jsem funkce tohoto zaˇr´ızen´ı. Zabýval jsem se strukturou celé aplikace a implementoval chován´ı základn´ıch prvk˚u.

Kl´ıˇcov´

a slova

ˇ

zelezniˇcn´ı stavˇedlo, kombinovan´a simulace, XML, Java, OOP

Abstract

Railway interlocking is a dispatching facility for traffic control. The dispatcher controls train paths by setting switches and signals. In this thesis, I describe the design and implemen-tation of a simple simulator of the facility in the Java language. I have studied functions of this facility. I interested with structure of whole application. And I implemented behaviour of foundamental elements.

Keywords

railway interlocking, combined simulation, XML, Java, OOP

Citace

Bedˇrich Hovorka: Simulátor ˇzelezniˇcn´ıho stavˇedla, bakaláˇrská práce, Brno, FIT VUT v Brnˇe, 2007

(6)

Prohl´

aˇsen´ı

Prohlaˇsuji, ˇze jsem tuto bakaláˇrskou práci vypracoval samostatnˇe pod veden´ım Ing. Davida Martinka. Uvedl jsem vˇsechny literárn´ı prameny a publikace, ze kterých jsem ˇcerpal.

. . . . Bedˇrich Hovorka

10. kvˇetna 2007

c

Bedˇrich Hovorka, 2007.

Tato práce vznikla jako ˇskoln´ı d´ılo na Vysokém uˇcen´ı technickém v Brnˇe, Fakultˇe in-formaˇcn´ıch technologi´ı. Práce je chránˇena autorským zákonem a jej´ı uˇzit´ı bez udˇelen´ı oprávnˇen´ı autorem je nezákonné, s výjimkou zákonem definovaných pˇr´ıpad˚u.

(7)

Obsah

1 Uvod´ 2

1.1 Etapy a c´ıle . . . 2

2 Modelovan´y syst´em a existuj´ıc´ı implementace 4 2.1 Zelezniˇˇ cn´ı stavˇedlo . . . 4

2.2 Existuj´ıc´ı implementace . . . 4

3 Teorie 6 3.1 Numerick´e metody . . . 6

3.2 Modelov´an´ı a simulace . . . 7

3.2.1 Diskr´etn´ı simulace . . . 7

3.2.2 Spojit´a simulace . . . 8

3.2.3 Kombinovan´a simulace . . . 8

4 Pouˇzité jazyky a nástroje 10 4.1 XML . . . 10 4.1.1 Analyzátory XML . . . 10 4.2 Java . . . 11 4.3 JDisco . . . 12 4.3.1 R´ızen´ı simulaceˇ . . . 12 5 Návrh a implementace 13 5.1 Rozdˇelen´ı do modul˚u – bal´ık˚u . . . 13

5.2 S´ıt’ a datov´y model . . . 15

5.2.1 Prvky s´ıtˇe . . . 16

5.2.2 Dynamick´a konfigurace a cesty v s´ıti . . . 17

5.2.3 Datov´y soubor . . . 17

5.3 Simulace . . . 17

5.3.1 Vstupnˇe-v´ystupn´ı body – InOut . . . 17

5.3.2 J´ızda vlaku . . . 18

5.4 Pˇr´ıklad – V´yhybna . . . 18

6 Z´avˇer 21 6.1 N´amˇety na rozˇs´ıˇren´ı . . . 21

(8)

´

Uvod

V této bakaláˇrské práci jsem se zabýval problematikou dopravn´ı simulace. Moje práce spoˇc´ıvala v nastudován´ı souˇcást´ı systému, experimentován´ım s existuj´ıc´ımi implementacemi her ˇr´ızen´ı ˇzelezniˇcn´ı dopravy, nalezen´ım vhodné simulaˇcn´ı knihovny a jako hlavn´ı ˇcinnost´ı – návrhem a implementac´ı základu simulátoru. Nejprve bylo tˇreba navrhnout strukturu aplikace, vnitˇrn´ı reprezentac´ı modelu a formát dat. Poté jsem mohl s vnitˇrn´ı reprezentac´ı implementovat grafické rozhran´ı umoˇzˇnuj´ıc´ı editaci. Dále jsem se uˇz zabýval pˇredevˇs´ım simulaˇcn´ım modelem.

V druhé kapitole pˇredstav´ım modelovaný systém. Jeho chován´ı je lépe ukázat na jiˇz existuj´ıc´ıch programech.

V tˇret´ı kapitole se zm´ın´ım o numerickém ˇreˇsen´ı diferenciáln´ıch rovnic. V dalˇs´ı sekci naraz´ıte na základn´ı pojmy z modelován´ı a simulace. Letmo se zm´ın´ım i o tom co to je diskrétn´ı, spojitá a kombinovaná simulace, u kombinované trochu podrobnˇeji.

Ve ˇctvrté kapitole popisuji sp´ıˇse neˇz bˇeˇznˇe známé vlastnosti pouˇzitých nástroj˚u, vlastn´ı postˇrehy a pˇr´ıklady z implementace. To plat´ı hlavnˇe o sekc´ıch o Javˇe a XML. V sekci o simulaˇcn´ı knihovnˇe jDisco struˇcnˇe vysvˇetl´ım, jak se pouˇz´ıvá, aby nedoˇslo k nˇekterým nedorozumˇen´ım, co jsem musel dále v implementaci ˇreˇsit a co ne.

Do páté kapitoly sem vybral, podle mého, d˚uleˇzité myˇslenky z návrhu a popisu imple-mentace. Do podrobnost´ı zacház´ım v pˇr´ıpadˇe, ˇze mi to pˇripadá nutné. Nejprve se zamýˇsl´ım nad celkovou strukturou aplikace. Poté pop´ıˇsu organizaci prvk˚u v systému. Následováno popisem jak je implementována simulace. A nakonec pˇredstav´ım pˇr´ıklad demonstruj´ıc´ı, to co bylo naimplementováno.

V závˇereˇcné kapitole projdu nˇekterá moˇzná rozˇs´ıˇren´ı, zejména ty které úzce navazuj´ı na souˇcasnou implementaci. Toto sekci následuje jiˇz jen zhodnocen´ı celé práce.

Nˇekteré názvoslov´ı bylo pouˇzito z [1] a existuj´ıc´ıch implementac´ı. Také názvy v obrázkách a schématech budou vˇetˇsinou anglicky, aby odpov´ıdaly zdrojovým kód˚um. Pro pochopen´ı tohoto textu pˇredpokládám, ˇze ˇctenáˇr je alespoˇn zbˇehlejˇs´ım studentem informatiky a rozum´ı pojm˚um z diskrétn´ı a numerické matematiky, algoritm˚u a objektové orientace.

Pˇr´ıklad odkazu do zdrojov´ych soubor˚u:Example.

1.1 Etapy a c´ıle

Co bylo implementováno pˇred bakaláˇrským projektem

Bˇehem Semestráln´ıho projektu vytvoˇril prototyp objektového modelu s´ıtˇe, zejména statické vlastnosti. Na základˇe toho jsem navrhl XML formát a implementoval továrnu pro naˇc´ıtán´ı

(9)

a ukládán´ı. V rámci projektu do Modelován´ı a simulace jsem vytvoˇril kombinovaný model pohybu vlaku podle dané posloupnosti semafor˚u a hran (ne v s´ıti). Do pˇredmˇetu Tvorba uˇzivatelských rozhran´ı jsem odevzdal jednoduchý grafický editor výˇse zm´ınˇeného modelu s´ıtˇe, který zobrazuje s´ıt’ v zaˇzitém schématu obdobném tomu pouˇzitém v elektronických stavˇedlech. Vˇse jsem bˇehem bakaláˇrského projektu doplnil do následuj´ıc´ıch c´ıl˚u:

C´ıle bakal´aˇrsk´eho projektu

Vytvoˇrit j´adro pˇrenositeln´eho programu:

• na základˇe nastudovaných podklad˚u navrhnout rozˇsiˇritelný systém tˇr´ıd, propojitelné komunikuj´ıc´ı moduly

• Dynamické vlastnosti a chován´ı základn´ıch prvk˚u – semafor, výhybka, kolej • Pohyb a lokalizace vlak˚u v s´ıti

• Datová struktura pro manipulaci z cestou, zejména stavˇen´ı cest (bez jejich ruˇsen´ı) • Vytvoˇrit pˇr´ıklad, který demonstruje funkˇcnost výˇse zm´ınˇených c´ıl˚u

(10)

Modelovan´

y syst´

em a existuj´ıc´ı

implementace

V této kapitole budou struˇcnˇe popsány funkce modelovaného systému. Dále uvedu nˇekteré jiˇz existuj´ıc´ı aplikace. Budou zde zm´ınˇena i fakta, která je tˇreba brát v úvahu, i kdyˇz jejich implementace nebyla dokonˇcena.

2.1 Zelezniˇ

ˇ

cn´ı stavˇ

edlo

ˇ

Zelezniˇcn´ı stavˇedlo je zaˇr´ızen´ı, které umoˇzˇnuje ˇr´ıdit dopravn´ı s´ıt’ nˇejakého uzlu ˇci trat’ového ´

useku z jednoho m´ısta. Ovládá chován´ı nˇekolika prvk˚u. Napˇr´ıklad nastavuje signály na semaforech a pˇrestavuje výhybky. Nˇekterá dneˇsn´ı stavˇedla maj´ı poˇc´ıtaˇcové rozhran´ı a jsou ovládána jedn´ım dispeˇcerem. Ten kaˇzdému vlaku vymez´ı urˇcitou cestu, tak ˇze zadá poˇcáteˇcn´ı a c´ılový semafor. Na stavˇedlu je pak, aby naˇslo nejvhodnˇejˇs´ı neobsazenou cestu. 1. Pokud ji nenajde z d˚uvodu obsazen´ı vˇsech moˇznost´ı uloˇz´ı poˇzadavek (dvojici – poˇcátek a c´ıl) do fronty. Pˇri uvolˇnován´ı kolej´ı testuje moˇznost sestavit prvn´ı prvek ve frontˇe. Frontu je moˇzné editovat.

2. V opaˇcn´em pˇr´ıpadˇe nastav´ı prvky v cestˇe

Toto souvis´ı i z bezpeˇcnost´ı. Systém nesm´ı na kaˇzdé koleji dovolit v´ıce neˇz jednu vlakovou cestu1. Jak m˚uˇze takový simulátor vypadat prozrad´ı následuj´ıc´ı sekce.

2.2 Existuj´ıc´ı implementace

Pro lepˇs´ı pˇredstavu jak taková aplikace funguje zde popisuji nˇekteré jiˇz existuj´ıc´ı simulátory ˇr´ızen´ı ˇzelezniˇcn´ı dopravy. Sice se vesmˇes jedná o hry, ale svoj´ı koncepc´ı se bl´ıˇz´ı k trenaˇzéru reálného systému. Zachovávaj´ı si vˇsak jednoduchost ovládán´ı. Pouˇzil jsem je také jako prostˇredek pro analýzu systému. Experimentován´ım s tˇemito programy jako metodou zpˇ et-ného inˇzenýrstv´ı2 lze nastudovat strukturu a chován´ı vˇetˇsiny systému. Kaˇzdý má svá národn´ı specifika (detaily v pravidlech ˇr´ızen´ı), vˇsak mnoho princip˚u je spoleˇcných, které popisuji u prvn´ıho. U dalˇs´ıch zmiˇnuji jiˇz jen rozd´ıly.

1_{Existuj´ı i tzv. posunov´}_{e, ale ty zat´ım neuvaˇ}_zuji 2

(11)

Staniˇc´aˇr

Tento hern´ı simulátor má modelovat ˇceské JOP. Uˇzivatel si zvol´ı ˇcas a stanici. Stanice a vlaky je uloˇzena v 1 velkém XML souboru. Poté se mu zobraz´ı kolejiˇstˇe a seznam vlak˚u v systému. Nyn´ı m˚uˇze ovládat jednotlivé prvky a sledovat chován´ı systému. Do kolejiˇstˇe urˇcenými m´ısty vj´ıˇzdˇej´ı vlaky (podle j´ızdn´ıho ˇrádu, generátor s exponenciáln´ım rozloˇzen´ım doby mezi generován´ımi). Úkolem dovést vlaky na m´ısto podle j´ızdn´ıho ˇrádu a udrˇzet plynulost dopravy. Kaˇzdá stanice ˇci vˇetˇs´ı systém má sv˚uj zásobn´ık (tak je zde nazývaná FIFO fronta) povel˚u, kam se uloˇz´ı kdyˇz zrovna nemohou být vykonány. U kaˇzdého vlaku je moˇznost prohl´ıˇzet j´ızdn´ı ˇrád (ˇcas, zastávka, ˇc´ıslo koleje). Stanice je moˇzné vytváˇret vlastn´ı v oddˇeleném editoru. Dále je tu i editor j´ızdn´ıch ˇrád˚u. V souˇcasné verzi funguje tato hra pod .NET 2.0 ve Windows. Dˇr´ıvˇejˇs´ı verze byly spustitelné v dotGNU.

SimSig

Tento britský simulátor podporuje sice v´ıce stanic, ale kaˇzdá má sv˚uj vlastn´ı instalátor. Funkˇcnˇe je obsáhlejˇs´ı. Um´ı simulovat výpadek elektˇriny, náhodné výluky v r˚uzných ˇcástech s´ıtˇe. a dalˇs´ı poruchy vlak˚u a s´ıt’ových prvk˚u. Je tu také urˇcitá m´ıra automatického ˇr´ızen´ı i v rozvˇetveném kolejiˇsti (proveden´ı j´ızdn´ıho ˇrádu). Sice urˇcená pro Windows, ale na rozd´ıl od pˇredcházej´ıc´ıho sem ji spustil i ve wine3.

Gordikon, Multikon, Brno S´ıt’ je nastavena napevno. Oproti ostatn´ım jsou na zaˇcátku simulace také vlaky um´ıstˇeny na kolej´ıch v s´ıti, nejenom, ˇze napˇred mus´ı vstoupit do systému zvláˇstn´ım prvkem v s´ıti, coˇz je reálnˇejˇs´ı.

3

(12)

Teorie

V této kapitole popisuji nˇekteré teoretické základy. Pojmy jakomnoˇzina ˇci relace pˇ redpo-kládám, ˇze ˇctenáˇr zná.

3.1 Numerick´

e metody

K výpoˇctu diferenciáln´ıch rovnic na ˇc´ıslicových poˇc´ıtaˇc´ıch bývaj´ı nejvhodnˇejˇs´ı numerické metody, nebot’ jsou zde operace provádˇeny diskrétnˇe. Spojité výpoˇcty je nutné na nˇe pˇrevést. A právˇe t´ımto pˇrevodn´ım prostˇredkem jsou numerické metody. V závislosti na pouˇzit´ı je nezbytné prozkoumat jejich vlastnosti jako je pˇresnost a stabilita ˇreˇsen´ı. Touto problema-tikou se podrobnˇeji zabývá [10]. Zmenˇsován´ım kroku se zvyˇsuje pˇresnost výpoˇctu (r˚uznˇe u r˚uzných metod), vˇsak pˇri velmi malých kroc´ıch uˇz hraje roli nepˇresnost elementárn´ıch operac´ı ˇc´ıslicové aritmetiky.

Jako pˇr´ıklad zde uvád´ım jednokrokovou metodu ˇreˇsen´ı ODR z poˇcáteˇcn´ımi podm´ınkami – Runge-Kutta-Fehlberg (rovnice 3.1 - 3.7), protoˇze je dále v této práci pouˇzita. Je pátého ˇrádu a nav´ıc m˚uˇzeme mezihodnoty kn zkombinovat na aproximaci ˇctvrtého ˇrádu (rovnice

3.8). Z té pak m˚uˇzeme vypoˇc´ıtat odhad chyby y_n₊₁−y∗_n₊₁ . Vyuˇzit´ı tˇechto vlastnost´ı viz sekce 3.2. Na obrázku 3.1 vid´ıme jej´ı pouˇzit´ı, kdyˇz oˇcekáváme výsledek bl´ızký polynomu druhého stupnˇe.

k1 = f(xn, yn), (3.1) k2 = f(xn+ 1 4h, yn+ 1 4hk1), (3.2) k3 = f(xn+ 3 8h, yn+ 1 32h(3k1+ 9k2)), (3.3) k4 = f(xn+ 12 13h, yn+ 1 2 197h(1 932k1−7 200k2+ 7 296k3)), (3.4) k5 = f(xn+h, yn+h( 439 216k1−8k2+ 3 680 513 k3− 845 4 104k4)), (3.5) k6 = f(xn+ 1 2h, yn+h(− 8 27k1+ 2k2− 3 544 2 565k3+ 1 859 4 104k4− 11 40k5)) (3.6) y_n₊₁ = yn+h( 16 135k1+ 6 656 12 852k3+ 28 561 56 430k4− 9 50k5+ 2 55k6) (3.7) y_n∗₊₁ = yn+h( 25 216k1+ 1 408 2 565k3+ 2 197 4 104k4− 1 5k5) (3.8)

(13)

-20 -15 -10 -5 0 5 -1 0 1 2 3 4 5 6 analytic result aprox inf(0) substepk2

Obr´azek 3.1: Demonstrace kroku metody

3.2 Modelov´

an´ı a simulace

V této sekci uvád´ım základn´ı pojmy z modelován´ı a simulace. Podrobnosti v [11,6]

Systém je cokoliv u ˇceho m˚uˇzeme popsat jeho chován´ı. M˚uˇze být reálný i imaginárn´ı. Napˇr´ıklad ˇzelezniˇcn´ı s´ıt’ s vlaky a ˇr´ıd´ıc´ımi prvky.

Prvek systému je elementárn´ı, dále nedˇelitelná, ˇcást systému. Vzájemná interakce prvk˚u urˇcuje chován´ı celého systému. Napˇr´ıklad kolejový odd´ıl. Zde záleˇz´ı na m´ıˇre abstrakce.

Model je systém, který napodobuje vlastnosti a chován´ı p˚uvodn´ıho systému.

Modelován´ı je postupné vytváˇren´ı model˚u. Z pozorován´ı a studován´ı systému vznikne

konceptuáln´ı model, coˇz je soubor neurˇcitých informac´ı (nástin). Z nˇej vytváˇr´ıme

abstraktn´ı model – form´aln´ı popis syst´emu. A z toho pak izomorfn´ım zobrazen´ım naprogramujeme simulaˇcn´ı model.

Simulace Z´ıskáván´ı nových znalost´ı o systému experimentován´ım se simulaˇcn´ım modelem.

Reálný ˇcas skuteˇcný ˇcas, ve kterém bˇeˇz´ı model

Modelov´y ˇcas ˇcasov´a osa modelu

Strojový ˇcas ˇcas, který byl potˇrebný k výpoˇctu (tj. jak dlouho byl procesor pˇrepnut do kontextu daného procesu)

3.2.1 Diskr´etn´ı simulace

Stav vˇsech prvk˚u je definován pouze v diskrétn´ıch ˇcasových okamˇzic´ıch. Bˇehem tohoto okamˇziku je provedena atomická operace zvaná událost, která tento stav m˚uˇze zmˇenit.

(14)

model_time = event.time event.behaviour()

3.2.2 Spojit´a simulace

Stav kaˇzdého prvku je definován v kaˇzdém okamˇziku vymezeného ˇcasového intervalu. Abs-traktn´ım modelem jsou algebraické, diferenˇcn´ı ˇci diferenciáln´ı rovnice a jejich soustavy. U jednokrokových metod lze na základˇe odhadu chyby mˇenit krok a t´ım urychlit výpoˇcet. Metoda uvedená v sekci 3.1má takové vlastnosti.

#zneplatnˇen´ı pˇredch´azej´ıc´ıch zmˇen (derivace=0)

for variable in all_variables : variable.state_fix() #v´ypoˇcet zmˇen stav˚u z pˇredch´azej´ıc´ıch

for continous in all_cont_processes : continous.derivatives() integrate() #krok numerick´e metody s posunem modelov´eho ˇcasu

3.2.3 Kombinovan´a simulace

Systém obsahuje spojité i diskrétn´ı prvky. ˇR´ızen´ı simulace mus´ı pˇri výpoˇctu spojitých stav˚u mˇenit krok, aby dokroˇcila k naplánované diskrétn´ı události. Dále mus´ı detekovat stavové podm´ınky a naplánovat proveden´ı události k podm´ınce pˇriˇrazené. Z numerických metod jsou proto vhodné jednokrokové, protoˇze u nich záleˇz´ı jen na pˇredchoz´ım výsledku.

Petriho s´ıt’ pˇri vytv´aˇren´ı kombinovan´eho modelu

Bˇehem návrhu aplikace jsem pouˇzil Petriho s´ıt´ı k pˇrehlednému vyjádˇren´ı proces˚u. Takto jsem si lépe pˇredstavil pr˚ubˇeh simulace a jak ho mám vyjádˇrit v programovac´ım jazyce. Vesmˇes se jednalo o C/E s´ıtˇe, tj. m´ısto, zde zvané podm´ınka, obsahuje maximálnˇe jednu znaˇcku a pˇrechod, zde nazývaný událost, je proveditelný v pˇr´ıpadˇe, ˇze vˇsechny podm´ınky pˇred n´ım plat´ı a podm´ınky za n´ım neplat´ı. V závislosti na lepˇs´ım vyjádˇren´ı jsem pˇrechody prohlásil bud’ za události reaguj´ıc´ı na stavovou podm´ınku, která ruˇs´ı platnost znaˇcky pˇred n´ı, nebo za spojitý proces a m´ısto za n´ım je stavová podm´ınka, na kterou ˇceká následuj´ıc´ı událost.

Mimo jiné jsem je také mohl ovˇeˇrit pomoc´ı nástroje CESim (viz [8]), pokud se s´ıt’ dala vyjádˇrit, aniˇz by to bylo na úkor pˇrehlednosti. Napˇr´ıklad s´ıt’ na obrázku 6.1 je t´ımto nástrojem ovˇeˇrená.

V s´ıti na obrázku 3.2 se nav´ıc nacházej´ı extern´ı podm´ınky a priorita. Proces se vrac´ı do stejného stavu – tj. je pˇred návˇestidlem , kdyˇz vlak dojede k dalˇs´ımu návˇestidlu nebo zmˇenou signálu skonˇcilo ˇcekán´ı pˇred n´ım. Podm´ınky

”red“ a”allowing signal“ pˇredstavuj´ı stav tohoto n´avˇestidla a samozˇrejmˇe vˇzdy1 plat´ı pr´avˇe jedna z nich. Podm´ınkou

”v ≤ 0, next red“ a prioritou oˇsetˇruji moˇznost zastaven´ı na konci následuj´ıc´ıho bloku, kterému pˇrecházelo rozjet´ı na jeho zaˇcátku.

1

(15)

(16)

Pouˇ

zit´

e jazyky a n´

astroje

Tato kapitola popisuje jazyky resp. nástroje, které jsem pouˇzil ve své práci. S Javou a XML sem se seznámil jiˇz dˇr´ıve, proto nechci zacházet do podrobnost´ı. Uvád´ım zde hlavnˇe rysy jazyk˚u resp. nástroj˚u týkaj´ıc´ı se této práce jako zd˚uvodnˇen´ı, proˇc sem tyto jazyky ˇci nástroje pouˇzil a pˇr´ıpadnˇe pro co byly v mé v mé práci nevhodné.

4.1 XML

XML je standardizovaný znaˇckovac´ı jazyk pro ukládán´ı r˚uzných typ˚u dat. Rozˇsiˇruje text o znaˇcky, zvané tagy, ty jsou uzavˇreny do < >, maj´ı název a mohou m´ıt nˇekolik atribut˚u. Tagy jsou poˇcáteˇcn´ı (zaˇc´ınaj´ı<), koncové (zaˇc´ınaj´ı< /) nebo “obojetné” (poˇcáteˇcn´ı s /

pˇred >). Vyuˇz´ıvá v r˚uzných oblastech, jako napˇr´ıklad webové stránky, vektorová grafika, katastr nemovitost´ı, serializace objekt˚u (v JavaBeans), a samozˇrejmˇe také pro ukládán´ı model˚u v M&S (napˇr. Ptolemy II.).

XML definuje obecnou syntaxi, ve které je moˇzné vytváˇret vlastn´ı znaˇcky. Vnitˇrn´ı re-prezentaci pˇredstavuje n-árn´ı strom r˚uzných typ˚u uzl˚u jako element, atribut, text atd. Data tedy mohou být rozm´ıstˇena hierarchicky podle logických vazeb. Snadno se rozˇsiˇruje a podporován mnoho jazyky, coˇz umoˇzˇnuje vytváˇren´ı datových formát˚u postupnˇe proto-typován´ım. D´ıky jmenným prostor˚um lze do dokumentu jednoho typu vloˇzit ˇcást jiného (tˇreba jiˇz existuj´ıc´ıho). Napˇr´ıklad do popisu dopravn´ı s´ıtˇe, jeˇz pˇredstavuje hlavnˇe topologii, lze pˇridat ke kaˇzdé cestˇe jej´ı geometrické vlastnosti pomoc´ı extern´ıho vektorového grafického formátu. Pro strojovou výmˇenu dat je to výborný jazyk, vˇsak pro ruˇcn´ı zápis, ˇci dokonce programován´ı (napˇr. XSLT) se mi zdá nevhodný. ˇCasto je vhodné jej pˇred odeslán´ım pˇres s´ıt’ zkomprimovat, nebot’ se zde projevuje nevýhoda tohoto typu znaˇckován´ı – opakovaná informace nav´ıc.

4.1.1 Analyz´atory XML

Validace dokument˚u Lexikáln´ı a syntaktická pravidla jsou stejná pro vˇsechna XML. Tv˚urce XML aplikace urˇcuje aˇz sémantiku. ˇCásteˇcnˇe mu mohou být nápomocny následuj´ıc´ı definiˇcn´ı nástroje. Pro urˇcen´ı jak má vypadat tzv. správnˇe formulovaný dokument v XML slouˇz´ı Definice typu dokumentu (DTD), kde se urˇc´ı metadata – co m˚uˇze dokument obsa-hovat za tagy, jaké maj´ı atributy a co mohou obsahovat, ale jen na úrovni prvk˚u XML, chyb´ı napˇr´ıklad typová kontrola atribut˚u ap. Tud´ıˇz DTD nestaˇcilo a muselo vzniknout XML Schema [2], coˇz je XML aplikace popisuj´ıc´ı nav´ıc také objektové vazby mezi znaˇckami.

(17)

Pro zvolen´ı XML jako datového formátu hovoˇr´ı také to, ˇze jiˇz existuj´ı analyzátory pro r˚uzné jazyky Postaraj´ı se o lexikáln´ı a syntaktickou analýzu podle obecné XML gramatiky a pˇr´ıpadnˇe provedou validaci. Existuj´ı dva hlavn´ı – SAX a DOM. SAX procház´ı dokumen-tem a volá metody zaregistrovanéhoHandleru, kdyˇz naraz´ı na zaˇcátek ˇci konec elementu. Bˇehem tohoto pr˚uchodu m˚uˇze být provedena i validace. Pˇri analýze DOM se pouˇzije SAX k pˇrevodu textu na standardizovanou vnitˇrn´ı podobu dokumentu (strom). Proto se pouˇz´ıvá sp´ıˇse v programech, které potˇrebuj´ı náhodný pˇr´ıstup k r˚uzným úrovn´ım dokumentu, jako jsou editory a prohl´ıˇzeˇce. Avˇsak má-li aplikace vlastn´ı lepˇs´ı vnitˇrn´ı reprezentaci dat ˇci je tˇreba provádˇet dlouhé sekvenˇcn´ı transformace, je vhodnˇejˇs´ı SAX. V´ıce o XML v [5]

4.2 Java

Java je obecný objektovˇe-orientovaný programovac´ı jazyk. Jeho hlavn´ı výhodou je, ˇze se spouˇst´ı v prostˇred´ı virtuáln´ıho stroje, jehoˇz implementace je dostupná pro mnoho beˇzných operaˇcn´ıch systém˚u. Takˇze umoˇzˇnuje vyváˇret pˇrenositelné spustitelné soubory. Vybral jsem jej, ˇze s t´ımto jazykem mám nejv´ıc zkuˇsenost´ı. K implementaci jsem nakonec zvolil verzi 6 Standard Edition. Existuje i pˇrekladaˇc v GCC je vˇsak s nejnovˇejˇs´ı oficiáln´ı verz´ı nekompa-tibiln´ı. Nav´ıc od verze 7 by mˇela být otevˇrená jiˇz i oficiáln´ı verze (viz projekt OpenJava). Existuje mnoho publikac´ı – napˇr. [9,12]. Java od svého vzniku proˇsla ˇradou inovac´ı, leccos bylo doplnˇeno a nˇekteré knihovn´ı tˇr´ıdy jsou zavrˇzené. Proto nˇekteré informace ve starˇs´ı literatuˇre jsou zastaralé. Nejspolehlivˇejˇs´ım zdrojem je tedy [3]. V Javˇe jsem zvyklý psát kód tak, ˇze názvy promˇenných a metod samy o sobˇe komentuj´ı.

Kontejnery (Kolekce) Jsou obdobou STL z C++ a slouˇz´ı k ukládán´ı pˇredem nedefi-novaného mnoˇzstv´ı dat. V Javˇe jsou to objekty, tedy sami mohou být prvky jiné kolekce. Napˇr´ıkladMapslouˇz´ı k vytváˇren´ı zobrazen´ı objektu na objekt, ˇc´ımˇz sniˇzuje vytváˇren´ı refe-renc´ı pˇr´ımo v objektech a tedy i závislost kódu jedné tˇr´ıdy na jinou. Problematika kontejner˚u je v´ıce rozvedena v [7], avˇsak pˇri pouˇzit´ı Javy 5 je tˇreba brát zˇretel na to, ˇze kontejnery jsou parametrizované. Skládán´ım kolekc´ı jsem vytvoˇril vlastn´ı datové struktury. Pˇredevˇs´ım jsem doplnil nebo zcela definoval rozhran´ı a implementoval neoptimalizované prototypy. Z nich se mohou vyvinout úloˇziˇstˇe pˇr´ımo na m´ıru, vˇsak si stále mohou zachovat urˇcitou m´ıru obec-nosti. Napˇr´ıkladArray2DMapv rychlosti je srovnatelná sTreeMap, ale nejˇcastˇeji volanou je právˇe vybrán´ı poloˇzky a provád´ı se za kritických výpoˇct˚u. Zde ˇslo hlavnˇe o to minimalizovat vytváˇren´ı kl´ıˇcových objekt˚u dvojic´ı celých ˇc´ısel a pˇritom zachovat kompatibilitu zMap.

Výhody a nevýhody Svou syntax´ı v´ıce inklinuje k obecným jazyk˚um (C, C++), pˇresto mnoˇzstv´ım standardn´ıch knihoven dohán´ı mnohý skriptovac´ı jazyk. Pˇr´ısná statická ty-pová kontrola m˚uˇze na prvn´ı pohled zdrˇzovat vývoj, ale pˇri správném návrhu a pouˇzit´ı vhodných editor˚u naopak zrychluje odladˇen´ı, protoˇze se m˚uˇzu soustˇredit hlavnˇe na logické chyby v kódu. Co vˇsak narozd´ıl od skriptovac´ıch jazyk˚u postrádá je podpora funkcionáln´ıho programován´ı. Pro modelován´ı komplexn´ıch systém˚u se strukturami s rekurzivn´ı agregac´ı (napˇr. cesta, která je podtˇr´ıdou dráhy, rozsekaná na ˇcásti, které jsou také podtˇr´ıdami dráhy) je pro urˇcen´ı zprávy pos´ılané vˇsem ˇcástem z cesty bych radˇeji implementoval pomoc´ı de-legace a referenc´ı na metody. Zde totiˇz m˚uˇze vzniknout neúmˇerné mnoˇzstv´ı podobného (rozkop´ırovaného kódu), coˇz jsem ˇcásteˇcnˇe vyˇreˇsil pomoc´ı reflexe, ale toto ˇreˇsen´ı je nee-fektivn´ı, protoˇze se mus´ı nalézt metoda podle ˇretˇezce se jménem a ty ˇretˇezce

”evidovat“ nav´ıc.

(18)

bych mohl o kombinovanou simulaci rozˇs´ıˇrit. Ale proˇc, kdyˇz existuje jiˇz hotová, celkem snadno pouˇzitelná knihovna. Nav´ıc se obávám, ˇze by tato implementace sama o sobˇe vy-dala minimálnˇe na jeden samostatný projekt. Dalˇs´ı moˇznost´ı je spojen´ı pˇres nativn´ı metody s knihovnou v jiném jazyce (napˇr. SIMLIB). To je také ˇcasovˇe nároˇcné.

JDisco – [6] je bal´ık javových tˇr´ıd pro popis a simulaci kombinovaných model˚u. Byla vyvinuta na Roskilde University v Dánsku. Existuj´ı zde dva typy proces˚u: diskrétn´ı a

spojitý (jak bylo ˇreˇceno v 3.2). Mezi naplánovanými diskrétn´ımi procesy jsou neaktivn´ı fáze,ve kterých mohou být aktivn´ıspojité. Pro popis spojitých promˇenných slouˇz´ı tˇr´ıda

jDisco.Variable. Ta má dva hlavn´ı atributy: okamˇzitou hodnotu – state a okamˇzitou derivaci – rate. Spojité procesy vytvoˇr´ım zdˇedˇen´ım od jDisco.Continuous a povinnou implementac´ı metodyderivatives, ve které se pop´ıˇs´ı vztahy mezi promˇennými. Obˇe tyto tˇr´ıdy maj´ı metody start a stop, jimiˇz m˚uˇzu urˇcit, kdy má bˇeˇzet spojitý výpoˇcet jejich zavolán´ım v popisu události. Jinak ˇreˇceno lze takto definovat intervaly spojitosti proces˚u ˇci promˇenných. Zdˇedˇen´ım odjDisco.Processa implementován´ım metody actions vznikne diskrétn´ı proces. Implementac´ı rozhran´ıjDisco.Condition vytvoˇr´ım stavovou podm´ınku na kterou bude proces ˇcekat ve volan´ı metodywaitUntil. Dále bal´ık obsahuje dalˇs´ı tˇr´ıdy pro zjednoduˇsen´ı popisu modelu, také nˇekolik numerických metod (r˚uzné Monitory). Nebudu zde dˇelat jejich výˇcet. Dokumentaci této knihovny sem pˇridal2 k programové dokumentaci své práce. V´ıce tedy tam.

4.3.1 R´ızen´ı simulaceˇ

Simulace je ˇr´ızena na pozad´ı zvoleným Monitorem, který je zodpovˇedný za to, ˇze se: 1. stav modelu mˇen´ı spojitˇe mezi událostmi

2. diskrétn´ı události provedou ve správný ˇcas 3. provede sbˇer informac´ı o chován´ı modelu

Spojité procesy pracuj´ı paralelnˇe a jsou synchronizovány s diskrétn´ımi, které jsou pomoc´ı kalendáˇre provádˇeny kvaziparalelnˇe. V jednom okamˇziku simulace bˇeˇz´ı tedy bud’ jeden diskrétn´ı proces nebo Monitor ˇr´ıd´ı výpoˇcet nˇekolika spojitých. Proces je javové vlákno vzdávaj´ıc´ı se procesoru tˇesnˇe pˇred zavolán´ım Object.waitna sebe, zavolá Object.notify

procesu n´asleduj´ıc´ım v kalend´aˇri.

1

SimPack, JDEVS, pak nˇekolik stejnojmenn´ych JSim˚u a JavaSim˚u

2

(19)

Kapitola 5

N´

avrh a implementace

Tato kapitola je zamˇeˇrena na struˇcný popis implementovaných souˇcást´ı. Podrobnosti obsa-huje programová dokumentace a zdrojové soubory. Nejprve je popsána celková struktura zdrojových kód˚u a poté rozvedeny jednotlivé souˇcásti, pˇredevˇs´ım ty nejd˚uleˇzitˇejˇs´ı.

5.1 Rozdˇ

elen´ı do modul˚

u – bal´ık˚

u

´

Uplnˇe nejprve je tˇreba si uvˇedomit a m´ıt na pamˇeti celkovou strukturu aplikace, i kdyˇz z n´ı zat´ım budou implementovány nˇekteré ˇcásti. Mohlo by se stát, ˇze nˇeco naimplementuji a pak to budu pracnˇe pˇredˇelávat1, protoˇze to nep˚ujde spojit. Na obrázku 5.1jsou ve vyˇsˇs´ı abstrakci znázornˇeny základn´ı funkˇcn´ı moduly aplikace a komunikaci mezi nimy, tak jak jsem pˇredpokládal na zaˇcátku návrhu. Program má pracovat ve dvou módech: editace a simulace. Zde jsem se rozhodl, ˇze bude lepˇs´ı vytvoˇrit si obálku pro pˇr´ıstup k datovému mo-delu. Módy maj´ı spoleˇcné operace, ale také ty, které jsou moˇzné jen v tom urˇcitém módu. Toto tedy zapouzdˇruje rozhran´ı2_Context_{a jeho podrozhran´ı. Jeho zat´ım jedin´}_a

implemen-tace DefaultContextna prvn´ı pohled vypadá jako jako vˇsevˇedouc´ı tˇr´ıda ˇci jako odkladna neum´ıstitelných funkˇcnost´ı. Faktem ale je, ˇze jsou zde vˇetˇsinou soustˇredˇeny metody, pro-pojuj´ıc´ı r˚uzné ˇcásti programu. Pro základ projektu vˇsak nepotˇrebuji m´ıt zat´ım dvˇe r˚uzné implementace, postaˇc´ı dbát na oddˇelován´ı pomoc´ı rozhran´ı. Ale umoˇzˇnuje to, ˇze simulaˇcn´ı kontext nebude jen v pamˇeti, ale m˚uˇze být sd´ılen mezi aplikacemi napˇr´ıklad po s´ıti nebo v databázi.

Mezi moduly (bal´ıky) vznikaj´ı závislosti, tj. kód jednoho bal´ıku se odkazuje na jiný. Zvláˇst’ nepˇr´ıjemné jsou cyklické, které nejsou znakem dobrého návrhu, pokud vznikaj´ı neˇr´ızenˇe ve velkém mnoˇzstv´ı. Je-li snaha vytváˇret moduly co nejv´ıc nezávislé, bude kód znovupouˇzitelnˇejˇs´ı. Na obrázku5.2jsou znázornˇeny stanovené závislosti modul˚u v souˇcasné implementaci. Pˇredpokládám, ˇze ˇctenáˇri z toho vyplynou i tranzitivn´ı. Této zásady jsem drˇzel aˇz na nˇejaké výjimky, zanˇeˇz v budoucnu pravdˇepodobnˇe zaplat´ım. Zpˇetná závislost dat na kontextu je ale ˇreˇsena pˇres rozhran´ı. Nav´ıc tˇreba tˇr´ıda AbstractPathje sp´ıˇse základem pro bal´ık ˇr´ızen´ı.

Vˇsechny bal´ıky z obrázku 5.2 jsou také závislé na bal´ıku util, ten uˇz je závislý jen na standardn´ıch knihovnách. Zejména na kolekc´ıch, které rozˇsiˇruje o dalˇs´ı potˇrebné datové

1_bˇ_{ehem n´}_{avrhu nelze m´ıt na mysli vˇ}_{sechny detaily, obzvl´}_aˇ_{st’ tam kde se mˇ}_{en´ı poˇ}_{zadavky – tak se sem}

tam provede menˇs´ı pˇredˇel´avka

(20)

editing

inner model

structure changes

simulation

state changes

control

low level commands

commands

state

Obr´azek 5.1: Z´akladn´ı struktura aplikace a tok dat

gui

xml

sim

context

objects

(21)

struktury, jako napˇr´ıklad neorientovaný graf. O tˇechto strukturách v´ıce na stranˇe11. V n´ a-sleduj´ıc´ıch podkapitolách pop´ıˇsi dalˇs´ı bal´ıky jednotlivˇe.

5.2 S´ıt’ a datov´

y model

V této sekci je bl´ıˇze popsána vnitˇrn´ı reprezentace s´ıtˇe. [13] ˇCásteˇcnˇe jsem se inspiroval také v [4].

Z pohledu dispeˇcera je to neorientovaný graf G = (U, H). Ke kaˇzdé dvojici objekt˚u (uzel1, uzel2) kde uzel1 6= uzel2 je pˇriˇrazen maximálnˇe jeden objekt hrany. Tento graf (pˇredevˇs´ım jeho uzly) je um´ıstˇen ve dvourozmˇerném prostoru s celoˇc´ıselnými indexy. Tento prostor je jakýsi pseudorastr – matice objekt˚u. Hrana je rozdˇelena na ˇcásti a ty vyplˇnuj´ı volné buˇnky na pˇr´ımce3 _{mezi nimy. V kaˇ}_zd´_{e buˇ}_{nce se samozˇ}_rejmˇ_{e m˚}_uˇ_{ze nach´}_{azet nejv´}_yˇ_se

jeden objekt. Uzly jsou na hrany propojeny pomoc´ı urˇcen´ı okol´ı buˇnky (pˇri editaci je nalezena), které zapouzdˇruje výˇctový typ Cell.Segment. Kaˇzdá buˇnka má mnoˇzinu seg-ment˚u4 _{, a pouze do tohoto okol´ı lze ke kaˇ}_zd´_{e dvojici (}_{segment, uzel}_{) lze pˇ}_ripojit

ma-ximálnˇe jednu hranu. Z pohledu vlaku se blok, pˇredstavovaný hranou, m˚uˇze skládat z v´ıce odd´ıl˚u, mezi nimiˇz jsou dispeˇcerem neovlivnitelná (automatická) návˇestidla. Dále existuje tzv. TrackFacility – je to nejmenˇs´ı i v´ıce-odd´ılová jednotka, ve které se m˚uˇze nacházet maximálnˇe jeden vlak. Na obrázku 5.3 jsou znázornˇeny stavy koleje a co m˚uˇze vyvolat

reserved

occupied

free

train

command

Obr´azek 5.3: ˇZivotn´ı cyklusTrackFacility

jejich pˇrechod. Tyto stavy jsou diskrétn´ı a vyjádˇril jsem je pomoc´ı výˇctového typu. Mˇelo by být jasné, ˇze vlak m˚uˇze vjet pouze na rezervovanou kolej, také ˇze rezervovat nelze pokud jiˇz je rezervovaná ˇci obsazená. Rezervuje ji pˇr´ıkaz dispeˇcera a obsazuje resp. uvolˇnuje vlak.

3

Bresenham˚uv algoritmus

4

(22)

jsou n´asleduj´ıc´ı uzly orientovan´e.

V´yhybka je nastavena bud’ na hlavn´ı smˇer nebo do odboˇcky

Hlavn´ı n´avˇest mˇen´ıc´ı se sign´al

Vstupnˇe-výstupn´ı bod pˇredstavuje extern´ı kolejový systém. Nebo m˚uˇzou být jako rozˇs´ıˇren´ı propojeny dva uvnitˇr modelu bez simulaˇcn´ıho Workeru – podpora mimoúrovˇnových kˇr´ıˇzen´ı.

Zakonˇcen´ı koleje konstantn´ı n´avˇest

”St˚uj“

• Hrany:TrackBlockObrázek5.4znázorˇnuje odvozen´ı bloku od dráhy. Jednu z moˇzných hran pˇredstavuje jednoduchá kolejSimpleTrackBlock. Je toTrackFacilitys jedn´ım odd´ılem. Dalˇs´ımi hranami mohou být mezistaniˇcn´ı úseky:

Automatick´y blok m´a v´ıce odd´ıl˚u – viz strana21

Poloautomatick´y blok facility, 1 hlavn´ı odd´ıl + 2 pˇredstaniˇcn´ı

« i n t er f ace » T rac kS ec ti on + en t er () + l eave () + ge tT rac k B l oc k() « i n t er f ace » P a t h + ge tL as tP a t hS emap h ore () + max S pee d() + reverse P a t h() + ge tFi rs t() + ge tL as t() + eq u a l s W i t h E l emen t s () « i n t er f ace » T rac k B l oc k + ge tN ex tT rac kS ec ti on () + i s I nner E l emen t () + ge tJ o i n () + max S pee d() « i n t er f ace» D eq u e « i n t er f ace» T rac kF ac ilit y + ge t S t a t e () « i n t er f ace » T rac k + i s F ree F rom () + se tU p P a th() + i s S e tU p P a th() + cance l P a t h S e t u p () + ge t S econ d E n d() + l eng t h() + max S pee d() + en d s ()

(23)

5.2.2 Dynamick´a konfigurace a cesty v s´ıti

Rezervovan´e koleje a dovoluj´ıc´ı sign´aly pˇredstavuj´ı jednu ˇci v´ıce tzv.

”postavených vlakových cest“. Tato cesta se j´ızdou vlaku postupnˇe rozpadá a m˚uˇze se za urˇcitých podm´ınek mˇenit. Formálnˇe je to cesta z teorie graf˚u tj. posloupnost uzl˚u a neobsazených hran, ale s ohledem na konfiguraci prvk˚u – konkrétnˇeji:

• poˇcáteˇcn´ı a koncový uzel je návˇestidlo ve smˇeru cesty ˇci vstupnˇe-výstupn´ı bod • výhybky propojuj´ı hrany (oba sousedy z posloupnosti)

• n´avˇestidla ve smˇeru mus´ı dovolovat j´ızdu, aˇz na posledn´ı, kter´e ji zakazuje

• protismˇerná návˇestidla: hlavn´ı zakazuj´ı (dále v nedoimplementovných – odd´ılová jsou vypnutá a na pˇredzvˇesti nemá cesta vliv)

Tato funkˇcnost5 je implementována v AbstractPath. Na obrázku 5.4 je také znázornˇena návaznost cesty na dráhu.

5.2.3 Datov´y soubor

Pro ukládán´ı a naˇc´ıtán´ı dat jsem navrhl tzv.ContextFactory. Zvolil jsem XML s validac´ı pomoc´ı XML Schema (viz4.1). Souˇcasný datový formát je v základn´ı podobˇe a pˇredstavuje skládán´ı prvk˚u s´ıtˇe na nejniˇzˇs´ı uˇzivatelem upravitelné úrovni. Pˇredstavuje statický popis s´ıtˇe stanice. Jednotivé uzly a hrany jsou obyˇcejnˇe vyjmenovány jako podelementy koˇrenového elementu. K rozliˇsen´ı typ˚u prvk˚u pouˇz´ıvám mj. výˇctové typy. Nejenˇze ˇsetˇr´ı m´ısto a jsou jednoduˇse rozˇsiˇritelné, ale snadno se i naˇc´ıtaj´ı a zapisuj´ı.

5.3 Simulace

Tato sekce popisuje pr˚ubˇeh simulace – neform´aln´ım popisem a pomoc´ı vybran´ych abs-traktn´ıch model˚u nejd˚uleˇzitˇejˇs´ıch proces˚u.

Proˇc kombinovan´a simulace?

Poloha vlaku se dá pojmout jak diskrétnˇe - tj. které kolejové obvody obsazuje. Také je vˇsak tˇreba znát jeho pˇresnˇejˇs´ı polohu, rychlost a zrychlen´ı v kaˇzdém okamˇziku. M´ıra pˇresnosti je nastavitelná. Umoˇzˇnuje v´ıce moˇznost´ı a lépe se mˇen´ı. Napˇr´ıklad lze zmˇenit rovnici v popisu pohybu.

5.3.1 Vstupnˇe-v´ystupn´ı body – InOut

Pˇredstavuje vstup a výstup do kolejiˇstˇe. Jeho chován´ı, jehoˇz základem je fronta vlak˚u, popisuje InOutWorker. V jednoduchých modelech lze do n´ı vkládat pˇr´ımo generátorem, ve sloˇzitˇejˇs´ıch to mus´ı provést vyˇsˇs´ı ˇr´ıd´ıc´ı logika – dispeˇcer. Sám o sobˇe um´ı povolit cestu k nejbliˇzˇs´ımu návˇestidlu orientovanému ve smˇeru j´ızdy, pokud výhybky k nˇejakému cestu propojuj´ı6 a zároveˇn je nˇejaký vlak ve frontˇe a zároveˇn jsou na n´ı volné vˇsechny koleje. V budoucnosti m˚uˇze pˇredstavovat pˇripojen´ı extern´ıho kolejiˇstˇe. Momentálnˇe uvaˇzuji modely o dvou InOut. Kdyˇz propoj´ım pouze dva tyto InOut jednou kolej´ı, rozpoutá se mezi nimi

5

pracuj´ıc´ı s hlavn´ımi n´avˇestidly, protoˇze ostatn´ı jsou uvnitˇr bloku

6

(24)

Vlak ˇceká ve frontˇe vstupnˇe-výstupn´ıho bodu na povolen´ı k j´ızdˇe. Po jeho z´ıskán´ı se spust´ı podproces Train.Front, který pˇri tom, kdyˇz naraz´ı na uzel (PathSeparator), pˇr´ıpadnˇe zmˇen´ı parametry podle nˇej a obsad´ı odd´ıl pˇred n´ım. Aˇz vyjede vlak celý spust´ı seTrain.Tail. Ten pˇri pr˚ujezdu kaˇzdým uzlem uvoln´ı odd´ıl za n´ım.

Kaˇzdé návˇestidlo poskytuje informaci o povolené rychlosti za n´ım a o signálu na n´ a-sleduj´ıc´ım návˇestidle, pokud ovˇsem nesv´ıt´ı signál

”St˚uj“. V tomto pˇr´ıpadˇe by mˇel vlak dobrzdit pˇred n´ım a ˇcekat na signál umoˇzˇnuj´ıc´ı j´ızdu. Pro zjednoduˇsen´ı pˇredpokládám, ˇze stav návˇestidel m˚uˇze být zjiˇst’ován pouze v diskrétn´ım stavu, kdyˇz vlak dojede k návˇestidlu, protoˇze stanovit, kdy m˚uˇze zaregistrovat zmˇenu signálu je v reálu neurˇcité narozd´ıl od programu.

Pˇri pr˚ujezdu kolem návˇestidla zaˇc´ıná mˇenit rychlost v závislosti na signálu. Tzv.

”rozjezd na výstrahu“, kdy se vlak u prvn´ıho návˇestidla zaˇc´ıná rozj´ıˇzdˇet a pˇred následuj´ıc´ım zastav´ı, je oˇsetˇrena zvláˇst’. Podprocesy konˇc´ı v koncových vstupnˇe-výstupn´ıch bodech InOut. Zde jsem zjednoduˇsil model pˇredpokladem, ˇze nejvˇetˇs´ı délka vlaku mus´ı být pˇreci menˇs´ı neˇz nejmenˇs´ı moˇzná délka kolejového bloku mezi dvˇema InOut. Takovéhle podobné okrajové pˇr´ıpady nemá cenu jinak oˇsetˇrovat, neˇz prohlásit model za chybný. Detekce této chyby vyˇzaduje hledán´ı minimáln´ıch cest.

Formálnˇe je to kombinovaný proces (viz sekce 3.2.3). Diskrétn´ı ˇcást ˇceká na stavové podm´ınky dojezdu k semaforu a nastavuje zrychlen´ı. Tuto interakci popisuje Petriho s´ıt’ na obrázku3.2, ta slouˇz´ı vˇsak jen pro názornost. Simulace nen´ı implementována pˇr´ımo pomoc´ı PS. Zvolil jsem jednouchý spojitý model, protoˇze je zhlediska odladˇen´ı diskrétn´ıch interakc´ı pˇredv´ıdatelnˇejˇs´ı. Základn´ı pohybové rovnice5.1a5.2pro zrychlen´ıa, rychlostva dráhus:

v = Z adt (5.1) s = Z vdt (5.2)

Výpoˇcet zrychlen´ıav rovnici 5.3z poˇcáteˇcn´ı rychlosti v0, c´ılové rychlostiv1 a dráhy s

pro zrychlov´an´ı:

∆v = v1−v0

a = ∆v(v1+v0)

2s (5.3)

5.4 Pˇ

r´ıklad – V´

yhybna

Pro lepˇs´ı demonstraci jak funguje simulaˇcn´ı model jsem vytvoˇril

”výhybnu“ ˇr´ızenou na základˇe jednoduchých pravidel. Ke kaˇzdému ovlivnitelnému návˇestidlu je na pevno pˇriˇrazena alespoˇn jedna vytvoˇrená cesta, která vede na dalˇs´ı kolej bud’ s moˇznost´ı odstávky ˇci opuˇstˇen´ı systému, tedy z urˇcitého pohledu pˇredstavuje jednu nedˇelitelnou operaci pˇresunu. Vlaky jsou vytváˇreny s jednoduchým j´ızdn´ım ˇrádem (dva údaje odkud, kam –InOut) pomoc´ı ge-nerátoru s exponenciáln´ım rozloˇzen´ım doby mezi jednotlivými generován´ımi. Dˇr´ıve neˇz jsou

(25)

pˇred vloˇzeny do frontyInOut, mˇelo by se pˇredej´ıt zahlcen´ı kolejiˇstˇe. ˇR´ıd´ıc´ı proces iterativnˇe proch´az´ı znalostmi o syst´emu:

1. zapomene vlaky, kter´e uˇz projely syst´emem

2. z vlak˚u, které ˇcekaj´ı na vstup vybere tolik, aby byly celkem v systému nejvýˇse dva a udˇel´ı jim souhlas (aktivován´ım procesu)

3. projde vˇsechny kolejov´e bloky

(a) ve kterých se nacház´ı vlak nebo je rezervovaná cesta, zjist´ı jeho resp. jej´ı smˇer – návˇestidlo ke kterému je vlak veden

(b) pokud je z tohoto návˇestidla volná cesta (pˇredem uloˇzená) postav´ı ji

Obrázek 5.5: Kolejové schéma výhybny

Ke schématu na obrázku5.5: úseˇcky jsou koleje, jejich spojen´ı jsou výhybky,•jeInOutaI je návˇestidlo. Po spuˇstˇen´ı simulace se na standardn´ı výstup programu vypisuj´ı po ˇrádkách zprávy:

1. j´ızda vlaku, spojit´y vzorek:

ˇ

cas objekt zrychlen´ı rychlost dr´aha kolej_od kolej_do vzd_n´avˇestidlo

2. diskr´etn´ı ud´alost prvku:

ˇ

cas objekt zpr´ava

dráha je celková dráha ujetá vlakem, kolej_od kolej na které se nacház´ı zaˇcátek vlaku,

kolej_dokolej na které se nacház´ı konec vlaku,vzd_návˇestidlovzdálenost k nejbliˇzˇs´ımu návˇestidlu.

V grafu na obrázku 5.6 je znázornˇeno, jak vlak v modelu reaguje na signály bˇehem události dojezdu k návˇestidlu. Zde je zrovna vidˇet jak ˇr´ıd´ıc´ı logika nestaˇc´ı povolit cestu do následuj´ıc´ıho bloku vˇcas, a vlak se mezi semafory rozj´ıˇzd´ı a zastavuje. V sekci 5.3.2 je vysvˇetleno chován´ı vlaku.

(26)

0 5 10 15

0 5 10 15 20 25 30 35 40 45 50

(27)

Kapitola 6

Z´

avˇ

er

V této kapitole jsou popsána moˇzná rozˇs´ıˇren´ı programu a zhodnocen´ı celé práce.

6.1 N´

amˇ

ety na rozˇ

s´ıˇ

ren´ı

Nápad˚u na to jak rozˇs´ıˇrit souˇcasnou aplikaci je plno, ale zde se zamˇeˇr´ım sp´ıˇse na ty, pro které je souˇcasná implementace pˇr´ımo navrˇzena, nebo z n´ı vyplývaj´ı a jsou v nejbliˇzˇs´ı dobˇe realizovatelné.

C´ıle v´ysledn´e aplikace

Tyto c´ıle jsem vytyˇcil z d˚uvodu, ˇze nechci, aby naimplementovaný kód byl vytvoˇren jen pro jeden úˇcel. T´ımto bych chtˇel nˇejak vyjádˇrit moˇznosti dalˇs´ıho rozvoje celé aplikace. Na mou práci mohou navázat a uskuteˇcnit je jin´ı studenti.

• grafický editor a simulátor ˇr´ızen´ıˇzelezniˇcn´ı s´ıtˇe v jedné aplikaci, zamˇeˇren´ı na funkˇcnost, minimalizace klikán´ı

• platformn´ı nezávislost – alespoˇn na úrovni zdrojových kód˚u

• formát dat, který umoˇzˇnuje vytváˇret ˇsablony prvk˚u kompozic´ı z jiných

Fyzik´aln´ı model j´ızdy

Pro souˇcasný popis j´ızdy existuje i analytické ˇreˇsen´ı. Popis pomoc´ı diferenciáln´ı rovnice ale umoˇzˇnuje jej´ı zmˇenu za sloˇzitˇejˇs´ı, která bude vˇernˇeji modelovat dalˇs´ı moˇzné pˇr´ıpady. Dráhu vlaku (hlavnˇe v mezistaniˇcn´ıch úsec´ıch) bych pojal jako kˇrivku v trojrozmˇerném prostoru – tj. dalˇs´ı vlastnost hrany. Pˇri tom je tˇreba rozloˇzit si souˇcasnou jedinou s´ılu udˇeluj´ıc´ı výsledné zrychlen´ı na nˇekolik sloˇzek – naklonˇená rovina v kopc´ıch, tˇren´ı, taˇzná s´ıla motoru, ta by mohla být ˇr´ızena napˇr´ıklad fuzzy regulátorem. M˚uˇzu pak uvaˇzovat i poruchy, pˇri které je s´ıla motoru nulová.

Automatick´y blok

Automatický blok (AB) je pevnˇe postavená, automaticky obnovovaná, cesta pro v´ıce vlak˚u. M˚uˇze to být napevnoTrackBlockposkládaný z nˇekolika odd´ıl˚uSimpleTrack. AB jako celek má dipeˇcerem nastavený smˇer. Jednotlivé odd´ıly okamˇzitˇe rezervuj´ı cestu v tom smˇeru, kdyˇz dojde k jejich uvolnˇen´ı. Na obrázku6.1je znázornˇeno chován´ı odd´ılu AB. AB by také mˇelo

(28)

druh˚u n´avˇest´ı (z´aleˇz´ı kde budou v s´ıti um´ıstˇeny):

Odd´ılov´a n´avˇest v autobloku

Pˇredzvˇest pomoc´ı konstantn´ı n´avˇesti s

”Volno“

Ukl´ad´an´ı stavu simulace

Diskrétn´ı proces je rozkouskovaný na události pˇr´ıkazy, jako je ˇcekán´ı, vedouc´ı ke ztrátˇe akti-vity. Pokud nˇejakým univerzáln´ım zp˚usobem vytvoˇr´ım moˇznost pamatovat stav ve kterém je kaˇzdý proces zrovna pasivn´ı mezi událostmi a definuji transformaci z poˇcátku do tohoto stavu, m˚uˇzu tuto informaci uloˇzit spoleˇcnˇe s dalˇs´ımi vlastnostmi pˇri serializaci. Proces by mohl být vnitˇrnˇe reprezentován jako automat ˇci Petriho s´ıt’ a jeho resp. jej´ı stav by se uloˇzil a obnovil. U spojitých promˇenných je tˇreba ukládatjDisco.Variable. Je moˇzné, ˇze kv˚uli univerzáln´ımu ˇreˇsen´ı, bude vyˇzadovat úpravy v knihovnˇe jDisco pro podporu serializace. Stav potomk˚u LoopProcess, který uvnitˇr iterace nepˇricház´ı do pasivn´ıho stavu, je moˇzné jiˇz ukládat.

Vizualizace pomoc´ı celul´arn´ıch automat˚u, Real-time

ˇ

Ctvercová s´ıt’ modelu pˇr´ımo pˇredurˇcuje pouˇz´ıt pro ˇr´ızen´ı vykreslován´ı celulárn´ı automaty. Snahou je minimalizovat mnoˇzstv´ı pˇrekreslované plochy a zbyteˇcnou výpoˇcetn´ı zátˇeˇz, zp˚ uso-benou procházen´ım stav˚u vˇsech bunˇek, omezen´ım pouze na malé mnoˇzstv´ı bunˇek nˇekterých typ˚u a u ostatn´ıch budu vycházet z pˇredpokladu, ˇze pokud se zmˇen´ı jedna buˇnka, tak pravdˇepodobnost zmˇeny v buˇnkách v okol´ı1 se nastav´ı na maximum a pak klesá s ˇcasem. Dále bude vhodné vytvoˇrit Monitor se synchronizac´ı reálného ˇcasu s modelovým. Ten by mˇel lépe detekovat a vhodnˇe vkládat

”odmlky“ mezi spojitý výpoˇcet. V souˇcasnosti to oˇsetˇruji diskrétn´ım procesem, který pro kaˇzdou sekundu modelového ˇcasu, po kterou ˇceká tj. simuluj´ı se jiné procesy, spoˇc´ıtá ubˇehlý ˇcas a vloˇz´ı pˇr´ımo potˇrebnou pauzu javového vlákna. Kvaziparalelismus zajist´ı, ˇze se pozdrˇz´ı výpoˇcet celé simulace. Je to tedy vloˇzen´ı jakýchsi synchronizaˇcn´ıch impuls˚u, které je vˇsak tˇreba naplánovat v lepˇs´ı okamˇzik.

(29)

Rozhran´ı do modelu pro ˇr´ızen´ı dispeˇcerem

Navázat je moˇzné na souˇcasnou formalizaci cest, doimplementovat jejich vyhledáván´ı. Vy-tvoˇrit bal´ıˇcek rutin a funkc´ı zastˇreˇsuj´ıc´ı pˇr´ıstup do modelu pro ˇr´ızen´ı z nˇekolika úrovn´ı. Na to také navazuje dodˇelat pˇr´ıkazy z GUI rozhran´ı. Vhodné bude zformalizovat posloupnost pˇr´ıkaz˚u jako jazyk, který se dá pˇr´ıpadnˇe optimalizovat.

6.2 Zhodnocen´ı dosaˇ

zen´

ych v´

ysledk˚

u

Program simuluje pohyb nˇekolika vlak˚u v s´ıti souˇcasnˇe. Kaˇzdý vlak se pohybuje podle bˇehem simulace stanovené cesty – reaguje na signály návˇestidel. Do obsazených kolej´ı nem˚uˇze vjet dalˇs´ı vlak. Stanovených minimáln´ıch c´ıl˚u bylo tedy dosaˇzeno, coˇz demonstruje pˇr´ıklad. Sloˇzitˇejˇs´ı s´ıt’ je rozumnˇe pˇredveditelná aˇz v pˇr´ıpadˇe doimplementován´ı ˇr´ıd´ıc´ıho mo-dulu a vizualizace simulace, kdy kontrolu mus´ı pˇrevz´ıt ˇclovˇek. Validita tohoto simulaˇcn´ıho modelu by ˇsla ovˇeˇrit sb´ırán´ım statistik o skuteˇcných vlakových s´ıt´ıch a srovnán´ım s mode-lem.

Vhodné rysy jazyk˚u resp. nástroj˚u nakonec pˇrevaˇzuj´ı, pˇrestoˇze nˇekteré konstrukce v nich byly obt´ıˇznˇeji vyjádˇritelné. Pokud jsem mˇel provˇeˇrit jakou zátˇeˇz´ı je simulace na operaˇcn´ı systém, vˇzdy se hodnoty bˇehem spuˇstˇené instance virtuáln´ıho stroje2 pohybovaly na mém pˇr´ıstroji kolem tˇechto hodnot a nijak výraznˇe se nemˇenily: sd´ılená pamˇet’ – 10 MB, kód a data ve fyzické pamˇeti – 25 MB, mnoˇzstv´ı virtuáln´ı pamˇeti – 213 MB, výkon CPU 91 % (toto nen´ı pokus o sofistikovanou výkonostn´ı analýzu, jenom jsem sledoval, zda si program nevynucuje zbyteˇcnˇe moc prostˇredk˚u).

Z vlastn´ı iniciativy jsem si vyzkouˇsel moˇznost pracovat na takovémto projektu a ponoˇrit se do problematiky analýzy a modelován´ı komplexn´ıch systém˚u, coˇz zahrnuje zabývat se pˇr´ıpadovými studiemi technických zaˇr´ızen´ı. Dále jsem si rozˇs´ıˇril obzor, o to jak zakom-ponovat simulaci, a zdokonalil se v návrhu a programován´ı aplikace. Problém jsem mˇel zejména ze zaˇcátku s odhadem ˇcasové nároˇcnosti prac´ı. Samotné kódován´ı ˇslo pomˇernˇe rychle, ale na ladˇen´ı jsem v odhadech ˇcasu pozapomnˇel. Radˇeji testuji pr˚ubˇeˇznˇe, chyba se potom snadnˇeji hledá. U rozsáhlých projekt˚u je vˇsak tˇreba jeˇstˇe vytváˇret testovac´ı skripty. V oblasti návrhu je stále se co uˇcit a v´ıce vyuˇz´ıt návrhových vzor˚u a hlavnˇe se drˇzet jejich zásad. Ale mus´ım poznamenat, ˇze doba strávená studován´ım a návrhem systému byla delˇs´ı neˇz doba programován´ı, kterou bych chtˇel v pokraˇcován´ı na výstavbˇe této aplikace jeˇstˇe zkrátit o vyvarován´ı se chybám, z kterých jsem se dopustil.

2

(30)

[1] Vyhláˇska Ministerstva dopravy, kterou se vydává dopravn´ı ˇrád drah. 1995. URLhttp://www.mvcr.cz/sbirka/

[2] XML Schema Part 1: Structures Second Edition. web, 2004. URLhttp://www.w3.org/TR/2004/REC-xmlschema-1-20041028/ [3] JDK 6 Documentation. web, 2006.

URLhttp://java.sun.com/javase/6/docs/

[4] FALKNER, A.; FLEISCHANDERL, G.: Configuration requirements from railway interlocking stations. Technick´a zpr´ava, Siemens Austria, 2001.

[5] HAROLD, E. R.; MEANS, W. S.:XML v kostce. Computer Press, 2002. [6] HELSGAUN, K.: jDisco – a Java package for combined discrete and continuous

simulation. Technick´a zpr´ava, Department of Computer Science, Roskilde University, 2001.

URLhttp://www.akira.ruc.dk/~keld/research/JDISCO/

[7] HEROUT, P.: Java - bohatstv´ı knihoven. Kopp, ˇCesk´e Budˇejovice, 2003.

[8] NOVOSAD, P.: Výukový nástroj pro práci s C/E Petriho s´ıtˇemi. InPedagogický software 2006, Zemˇedˇelská Fakulta, Jihoˇceská Univerzita, 2006, ISBN 80-85645-56-4, s. 247–249.

URLhttp://www.fit.vutbr.cz/research/view_pub.php?id=8103

[9] PECINOVSK ´Y, R.: Java 5.0 – Novinky jazyka a upgrade aplikac´ı. Computer Press Brno, 2005.

[10] REKTORYS, K.; kol.: Pˇrehled uˇzit´e matematiky I. - II.Prometheus, 2000.

[11] R ÁBOV Á, Z.; ˇCEˇSKA, M.; ZENDULKA, J.; aj.:Modelován´ı a simulace. VUT FEI, druhé vydán´ı.

[12] SPELL, B.: Java Programujeme profesionálnˇe. Computer Press Praha, 2002. [13] WR ÓBLEWSKI, P.: Algoritmy – Datové struktury a programovac´ı techniky.

(31)

Seznam pouˇ

zit´

ych zkratek

AB Automatický blok – trat’ové zabezpeˇcovac´ı zaˇr´ızen´ı rozdˇelené na prostorové odd´ıly

DOM Document Object Model – v´ıce v [5]

GCC GNU Compiler Collection – http://www.gnu.org/software/gcc/

JOP Jednotn´e obsluˇzn´e pracoviˇstˇe – ˇr´ıd´ıc´ı zaˇr´ızen´ı umoˇzˇnuj´ıc´ı kontrolovat nˇekolik stanic najednou

M&S Modelov´an´ı a simulace – viz sekce 3.2

PS Petriho s´ıt’ – viz sekce3.2

SAX Simple API for XML – v´ıce v [5]

SIMLIB SIMLIB/C++ –http://www.fit.vutbr.cz/~peringer/SIMLIB/

STL Standard Template Library – knihovn´ı funkce jazyka C++

XSLT eXtensible Stylesheet Language Transformations – funkcionáln´ı programovac´ı ja-zyk v XML pro specifikaci pˇrevodu vstupn´ıho XML na výstupn´ı formát (v´ıce v [5])