• Nie Znaleziono Wyników

Niektóre aspekty rozwoju modułu MAPA dla potrzeb symulatora ruchu pociągów

N/A
N/A
Protected

Academic year: 2022

Share "Niektóre aspekty rozwoju modułu MAPA dla potrzeb symulatora ruchu pociągów"

Copied!
14
0
0

Pełen tekst

(1)

ZESZYTY NAUKOWE POLITECHNIKI ŚLĄSKIEJ

Ser i T R A N S P O R T z. 16 Nr kol. 110'

Roman KONIECZNY

NIEKTÓRE ASPEKTY ROZWOJU MODUŁU MAPA DLA POTRZEB SYMULATORA RUCHU POCIĄGOW

Streszczenie. Moduł programowy MAPA jest składnikiem symulatora ruchu pociągów, którego zadaniem jest wizualizacja wyników symulacji na mapie topologicznej wybranego rejonu sieci. Prace związane z realizacja komputerowego symulatora ruchu pociągów prowadzone są w Instytucie Transportu Politechniki Śląskiej od roku 1966 - na zlecenie Instytutu Informatyki Uniwersytetu Warszawskiego w ramach programu RP. 1 .09 "Rozwój języków, metod oraz podstaw formalnych oprogramowania". Artykuł zawiera skrótowe omówienie całości oprogramowania symulatora ze szczególnym uwzględnieniem aktualnej wersji modułu MAPA. Dalsza jego częśó zawiera wybrane sugestie dotyczące dalszego usprawnienia oraz rozwoju tego modułu.

1 - Wpr owadzeni e

Oprogramowanie komputerowego symulatora ruchu pociągów powstało na bazie pracy poświęconej aplikacji języka LOGLAN Cna komputer IBM P O , wykonanej przez zespół pod kierunkiem autora w Instytucie Transportu Politechniki Śląskiej na zlecenie Instytutu Informatyki Uniwersytetu Warszawskiego w ramach programu badawczego RP.I.09 "Rozwój języków, metod oraz podstaw formalnych oprogramowania".

Rozwój oprogramowania realizowano kolejnymi 1-rocznymi etapami:

- 1986 - opracowanie koncepcji komputerowego makromodelu ruchu pociągów, rozważania na temat wyboru języka symulacyjnego, wybór języka LOGLAN C13;

- 1987 - badanie walorów funkcjonalnych i użytkowych LOGLANu, opracowanie wstępnej wersji symulatora ruchu pociągów C21;

- 1988 - rozszerzenie symulatora ruchu pociągów, opracowanie modułu MAPA w

Języku LOGLAN [33;

- 19S9 - przeprogramowanie modułu MAPA z Języka LOGLAN na Język Turbo PASCAL, zorganizowanie pracy makromodelu w wariancie dwukomputerowym C43;

- 1990 - przeprogramowanie symulatora ruchu pocia9^w 2 Języka LOGLAN na język Turbo PASCAL, zintegrowanie oprogramowania na bazie Tur to PASCALa C war i ant j ednok omputerowy3 .

Koni ępznpśó pr zępr OGr amowani a moduł ów. MAPA i SYMULATOR z języka LOGLAN n.«

(2)

1-46 Roman Koni eczny

język Turbo PASCAL wyniknęła z prozaicznej przyczyny - braku efektywnej implementacji kompilatora LOGLANu. ‘Język programowania LOGLAN w swych zasobach posiada bowiem niezbędne środki do symulacji systemów dyskretnych zdarzeń oraz programowania obiektowego [5,6,7,83, Jednakże brak kompilatora zmusił zespół do podjęcia decyzji o zmianie języka programowania. Język Turbo PASCAL wybrano ze względu na duże podobieństwo składniowe do LOGLAN-u oraz możliwość rozłącznej kompilacji modułów. Należy w tym miejscu, zwrócić uwagę na szczególnie dużą użyteczność LOGLAN-u do opracowania projektów programów symulacyjnych różnych systemów. które następnie mogą być implementowane w dowolnym języku programowania, posiadającym efektywny kompilator oraz odpowiednie środowisko.

D l a realizacji całości oprogramowania makromodelu na bazie języka

Turbo PASCAL w zupełności arczy jeden komputer. Wariant dwukomputerowy, aczkolwiek bardziej interesujący technicznie, posiada ponadto pewne w^Jy, takie jak:

- zbyt duża redundacja danych Cczęść danych z konieczności musi być dublowana w pamięci drugiego komputera!?,

- rozproszenie funkcji operatora programu symulującego Czbędna konieczność korzystania z dwóch klawiatur i dwóch ekranów},

- strata czasu na komunikację międzykomputerową,

- występujące niekiedy kłopoty techniczne w przypadku łączenia różnych klonów IBM PC na etapie promocyjnym.

Wymienione wady Cbrak kompilatora LOGLAN-u oraz niedogodności pracy dwuk cmput er owej 3 spowodowały, że na początku roku 1990 zdecydowano się zrealizować całość oprogramowania makromodelu w wariancie jednokomputerowym na bazie języka Turbo PASCAL Cwersja 5.03, gdzie moduł MAPA będzie zintegrowany z symulatorem w jednym programie.

Przeprogramowanie symulatora z jednego języka na drugi nie może być

j e d n a k celem samym w sobie, dlatego już teraz Cnie wnikając w korzyści

wynikłe z integracji modułów na jednym komputerze} należy przeanalizować z a g a d n i e n i e d a l s z e g o u s p r a w n i e n i a i rozwoju tego oprogramowania.

2 . O b e c n a i m p l e m e n t a c j a m o d u ł u MAPA

M o d u ł MAPA r e a l i z u j e d w i e p o d s t a w o w e f u n k c j e : - w y ś w i e t l a n i e o b r a z u s t a ł e g o C t o p o l o g i i s i e c i 3 ,

- wyświetlanie obrazu zmiennego Cwizualizacja wyników symulacji}.

Obraz stały jest zbiorem elementów graficznych, których parametry nie są zmieniane podczas trwania symulacji. Do zbioru tego należą wszelkie napisy, numery oraz zasadniczy szkielet topologii sieci. Obraz zmienny dotyczy pewnych elementów ujętych na mapie, których stan zmienia się w czasie trwania symulacji Cnp. zmiana stanu semafora, połączcriia, relacji, przesuw numeru pociągu}.

(3)

Niektóre aspekty rozwoju modułu MAPA. 149

Dane wejściowe do modułu MAPA przygotowywane są przy użyciu pomocniczego programu PREMAPA Cnapisanego w języku Turbo PASCAL wersja 3.03. Program PREMAPA, najogólniej rzecz ujmując, przetwarza źródłowy zbiór rekordów opisujących symbole obecne na mapie, na zbiór symboli uproszczonych Cw większości wektorów}, podlegających wyświetlaniu. ,

Ogólnie proces ten można zapisać następująco:

Z = <l' . T \ P \ s \ F- . c f . R- .M* . K‘>

w«kt o r y z a c j a P R E M A P A

Z ł= < L ł,P*,Sł,Gł,R*,Mł,N*>

gr upowani . « 1. s o r t o wa ni . «

< L " , P**, S " , G " , R " , M" , N**> * Z ” gdzie:

Z - plik wejściowy Cżródłowy}, Z' - plik pośredni,

Z" - plik wyjściowy Cwynikowy}, L - zbiór odcinków elementarnych, T - zbiór tekstów,

P - zbiór połączeń, S - zbiór semaforów,

F - zbiór semaforów fikcyjnych, G - zbiór opisów głowic, R - zbiór relacji, M - zbiór mikrorelacji,

N - zbiór napisów i miejsc wyróżnionych na mapie;

* - oznacza wektor z definicji,

* - podlega wektoryzacji, - nie podlega wektoryzacji.

W szczególności zachodzą następujące relacje:

CVCT*e 2D » L 3 ~ CYCP'1'« Z3 * Lf+P'3 ^ CVCST v F~e Z3 ¡» L^+S’2

gdzie L ,L ,L są odpowiednimi podzbiorami odcinków elementarnych powstałymi z T*,P*,S+ po procesie wektoryzacji,

znak * CprinO oznacza stadium nieuporządkowane Czbiór Z*3,

znak " Cbis3 oznacza stadium po uporządkowaniu Cplik wyjściowy Z"3.

Po zakończeniu przetwarzania otrzymuje się podzbiór wynikowy:

L M = L + L + L + L

T P S

Jest to uporządkowany według współrzędnej X zbiór wektorów. Pogrupowanie 1 posortowanie rekordów wynikowych ma na celu umożliwienie szybszego wyszukania elementów każdego nowego obrazu na ekranie przy przesuwie mapy.

Rekordy źródłowe Cwejściowe dla programu PREMAPA3 wpisywane są do pamięci komputera dowolnym edytorem tekstu. Program PREMAPA przetwarza zbiór Z na Z". Moduł MAPA dokonuje wizualizacji zbioru Z".

Programy PREMAPA i MAPA zostały szczegółowo opisane w pracach [33 i

(4)

150 Roman Koni eczny

[4,3. Jako ciekawostkę można zacytować tabelę nr 1. podającą efekty uzyskane po przeniesieniu wersji programu MAPA z języka LOGLAN na Turbo PASCAL wersja 5.0. Porównania dokonano na komputerze IBM PC/XT 4.77 MHz.

Tablica 1 Porównanie czasów wykonania niektórych czynności modułu MAPA

Lp. Czynność Czas trwania

LOGLAN [ s 3

Czas trwania PASCAL C s 3

Przyspi e- szeni e 1 Ładowanie pliku z danymi

topologicznymi mapy

480 17 28

2 Przeskalowanie całościowe

mapy 180 lO 18

3 Obliczenie obrazu dla pierwszej ramkiC "rozruch"}

programu 40 4 10

4 Przesuw mapy o 100 punktów 60 4 15

5 Wyszukiwanie Cprzypadek

najgorszy} 195 8 24

6 Wyszukiwanie Ctypowy

przypadek} 122 6 20

2ródło: Opracowanie własne

Proces budowy dowolnej mapy Cnie tylko kolejowej} na przedstawionej tutaj zasadzie jest prosty i skuteczny. Jest to niewątpliwą zaletą obu tych programów CMAPA i PREMAPA}. Natomiast do wad tego rozwiązania zaliczyć można:

— brak natychmiastowej wizualizacji na ekranie nowo wprowadzonego symbolu.

— brak własnego edytora symboli,

— zbyt duża zajętość pamięci Cgłównie przez podzbiór L*'} ,

— niezadowalająca szybkość budowy obrazu mimo zastosowania algorytmu o koszcie logarytmicznym Cwynika to z przyjętej koncepcji - wstępnej wektoryzacji symboli},

— konieczność pracy dwuetapow&j Cpotrzeba korzystania z pomocniczego programu PREMAPA}.

3. Zagadnienie rozwoju modułu MAPA

Ponieważ budowa map komputerowych jest zagadnieniem Ważnym Ca istniejące pakiety programowe typu AutoCAD czy OrCAD są drogie i nie zawsze można je bezpośrednio użyć w procesie symulacyjnym, względnie przy wizualizacji stanów innych procesów}, dlatego aspekty rozwoju modułu MAPA wydają się być ciągle aktualne.

Podstawowymi usprawnieniami modułu wizualizacji mapy mogą być:

(5)

Niektóre aspekty rozwoju modułu MAPA.

- utworzenie zintegrowanego środowiska programowego służącego do budowy i wizualizacji mapy*

- rozbudowanie procedur wyszukiwawczych, - stworzenie edytora fontów graficznych,

- przyjęcie koncepcji bieżącej wektoryzacji symboli przy budowie obrazu.

Koncepcja bieżącej wektoryzacji symboli umożliwia znaczną redukcję danych.

Ponadto niepotrzebne już będą pliki pośrednie Cczyli użycie programu PREMAPA w tym zakresie}.

Problem reprezentacji danych można zilustrować dla wersji mapy [3,43 w postaci pascalowskiego rekordu z wariantami:

type typ_rekordu_zr = CL»T,P,S,F,G,R,M,N};

rekord_zr = record

case rek: typ_r ekordu_zr of L: C X 1 ,Y1,X2,Y2.STYL: integer};

T: CXP.YP.WYS.SZER,ODSTĘP.STYL.RA: integer ; TEKST: stringC803};

P:CNRPOL,XI,Y1,X2,Y2: integer};

S.F: CNRSEM.XP.YP.XR,YR.RSEM: integer};

G: CNRGLO,LREL,SLMrel,XP,YP: integer};

R: CNRGLO,NRREL.PI,P2.LMrel: integer:

Mikrorel: array Cl..203 of integer};

M: C NRGLO,NRMi k r or e l .XI.Y 1 .X2.Y2:integer};

N:CXP.YP:integer: nazwa:stringC123}:

e n d :

Należy tutaj zwrócić uwagę, że w rzeczywistej deklaracji dla programu komputerowego wszystkie identyfikatory Cnazwy pól} rekordu musiałyby być różne. Stosowanie rekordów z wariantami w Języku Turbo PASCAL nie Jest zbyt efektywną techniką ze względu na nieoszczędną rezerwację pamięci przez kompi1 ator .

Rekordy źródłowe dla modułu MAPA można zorganizować według następujących założeń:

- zakłada- się "nieograniczony" zbiór danych CtJ. nie mieszczący się w pamięci wewnętrznej RAM},

- zakłada się rekordy o zmiennej długości, - zakłada się stosowanie kompresji danych,

- zakłada się operowanie na pamięci RAM podczas rysowania obrazu.

Ogólnie budowa rekordu źródłowego może być następująca:

(6)

152 Roman Konieczny

Typ jXI Y1 X2 Y2

Typ I--- ,-- 1--- rekordu współrzędne

obrysu prostokątnego symbolu na mapi e

inne parametry

Rekord jest zbiorem liczb typu i nteaer. Typ rekordu jest liczby ujemną o następujących znaczeniach:

—lOOOO < Typ <0 podstawowy Cniezależny!) rekord źródłowy, -20000 < Typ <-10000 rekord złożony CstrukturaD.

—30000 < Typ <-20000 rekord składnikowy rekordu złożonego.

Jak widaó z powyższego założenia, istnieje możliwość -rozróżnienia 1C000 typów podstawowych rekordów źródłowych oraz 10000 typów rekordów złożonych.

Wyczerpuje to praktycznie potrzeby występujące przy budowie map. Należy również dodać, że typ pierwotny i nteaer umożliwia narysowanie ną papierze milimetrowym mapy o wymiarach 32 x 32 metry. Jest to raczej tylko ciekawostka, gdyż praktyczne potrzeby nie idą nigdy tak daleko. Z punktu widzenia wyszukiwania danych rekord złożony jest grupą rekordów składnikowych Cbez żadnych innych konsekwencjiD .

Ideę wyszukiwania danych można zilustrować następującym uproszczonym schematem:

— ---- plik t a b l i c a t y p u ^ypu

< integer

1nteger - f— -

C parni ęć

T" Cpamięć RAM!) dyskowa!)

zakresy indeksów dla potrzeb wyświetlania ekranu bieżącego

Przyjmuje się, że PZ będzie posortowanym wg kluczy współrzęnych X i Y plikiem źródłowym o dostępie swobodnym o rozmiarze dążącym do

"nieskończoności*'; oraz że TR będzie tablicą roboczą w pamięci RAM o rozmiarze Cl.. MAX gdzie wielkość MAX jest możliwie duża, zależna tylko od sprzętu i od implementacji kompilatora!). Tablica TR stanowi kopię pewnego fragmentu pliku PZ; ID i IG są bieżącymi indeksami C dolnym i górnym!) w tablicy TR, określającymi zakres indeksowy dla potrzeb wyświetlania ekranu bieżącego. Przyjąć także należy, że MAX jest dużo większe od różnicy IG-ID.

Przy budowie obrazu wyróżnić należy następujące sytuacje:

— IG = MAX dojście "w prawo" do końca tablicy!) - wtedy należy uzupełnić tablicę TR o dane z pliku PZ; można to uczynić np. przez przepisanie "górnej" połowy tablicy TR na jej "dolną” połowę, a

"górną" połowę uzupełnić danymi przeczytanymi z PZ;

- ID - lCdojście w "lewo" do początku tablicy!) - wtedy należy "dolną"

(7)

Niekt,óre aspekty rozwoju modułu MAPA.

połowę tablicy TR przepisać na "górną" a "dolną" uzupełni odpowiednimi danymi z PZ.

W przypadku wyszukiwania rekordu symbolu o współrzędnych poza tablicą TR

—'w - « •— '

należy wykonać zwrot do pliku PZ, odnaleźć szukany rekord i skopiować Cwraz z nim} całe jego "połówkowe lewe" i "połówkowe prawe" otoczenie z PZ do TR.

Przyjęte rozwiązanie zapewnia płynne "chodzenie" po dużej mapie ber potrzeby kłopotliwego dzielenia jej na sektory lub strony. W przypadku wyrywkowego •* przęglądanią -b'ardzo dużej mapy Cduźej w sensie liczby zamieszczonych .. symboli a - nie np. rozpiętości między największym i najmniejszym X czy Y} można chwilowo zrezygnować z posługiwania się tablica TR, a dane odczytywać bezpośrednio 2 pliku PZ. Po zakończeniu wyrywkowego przeglądania mapy, program - korzystając z chwili przerwy - może skopiować wybrany Cdomniemany} fragment mapy z pliku PZ dp tablicy TR. Można p r z y j ą ć zasadę, że tablica TR stosowana będzie tylko do przyspieszenia dokładnego

.«i ' , -i

oglądu mapy w wybranych "lokalnych" rejonach. W przypadku dużych map pracujących na bieżąco tablicę TR; można powiększyć w komputerze na poprzez z a s t o s o w a n i e r o z s z e r z e n i a p a m i ę c i RAM.

Praktycznie dla potrzeb map dużego rejonu sieci kolejowej Cnp.

śląskiej DOKP} dane zawarte w pliku PZ całkowicie mieszczą się w tablicy TP.

Na rys. 1. pokazano problem optymalnego rozmieszczenia rekordów w pliku

, * » . _ i ■

Przy rozpatrywaniu kwestii optymalnego rozmieszczenia rekordów symboli w pliku PZ należy zwrócić uwagę, że dla wybranego skupiska symboli na

- V mapie moga wystąpić następujące sytuacje:

- symbol należy całkowicie do ekranu bieżącego Cnp. 61} , - symbol należy częściowo do ekranu Cnp. 50,73},

- symbol "przechodzi" przez ekran Cnp.57,59},

- symbol “zakrywa" ekran - jest tak duży, żę tworzy tło dla innych symboli Cnp. 52},

- symbol nakłada się na inny symbol Cnp.57,59},

- skupisko symboli jest "rozciągnięte" wzdłuż osi X lub Y.

Rekordy w pliku PZ można posortować według różnych kluczy:

- kolejności wprowadzania,

- odległości środka geometrycznego symbolu lub współrzędnej CX1,Y1} obrysu prostokątnego symbolu od początku układu współrzędnych lub np. od punktu có/S2 £ > .

2

Posortowanie pliku PZ ma na celu przyspieszenie wyszukiwania rekordów przy wyświetlaniu ekranu bieżącego. Analizując problem dokładniej stwierdzić można, że występują sytuacje nieoptymalnego wyszukiwania. Przykładowo dla wielu symboli rozciągniętych wzdłuż osi Y, ale posiadających tę samą lub zbliżoną współrzędną X środka geometrycznego, nastąpi niepotrzebne sprawdzenie obecności symbolu na ekranie, choć z góry wiadomo, że pewne grupy symboli i tak będą nieobecne Cnp. ciąg symboli 71 Cgóra} do 70 Cdółl-

(8)

154, Roman Konieczny

Rys.l. Ilustracja problemu optymalnego rozmieszczenia rekordów w pliku PZ Fig.l. An illustration of optimal 1 ay-out of records in PZ file

zob. rys. ID .

Proste posortowanie np. według współrzędnej XI może czasem grozić niebezpieczeństwem zgubienia Ctj. nie wyświetlenia} symbolu. Przykładowo:

obiekty wcześniej ułożone w pliku PZ C74*75,77} nie należą Już do ekranu bieżącego, ale “późniejszy" 78 należy. W algorytmie wyszukującym,, aby nie było takich przeoczeń symboli, należy przyjąć pewną strefę penetracji pliku PZ na tzw. obszar pozaekranowy. W zależności od charakteru mapy wyszukiwanie to może być bardziej lub mniej efektywne. Można też wprowadzić pewien limit maksymalnych rozmiarów pojedynczego symbolu. Założenie taki*

znakomicie upraszcza wyszukiwanie rekordów, niemniej jest ono nieco sztywne

(9)

Niektóre aspekty rozwoju modułu MAPA. 15b

i kłopotliwe przy wprowadzaniu symboli.

Dobranie właściwego klucza sortowania rekordów w pliku PZ jest kłopotliwe i nie zawsze daje efektywny algorytm wyszukiwania. Można zatem przyjąć inną koncepcję i założyć, że plik; PZ nie będzie nigdy sortowany Cułatwia to dopisywanie nowych rekordów}, natomiast wystąpią pomocnicze pliki Club tabliceD indeksowe PIX1 , PIY1, PIX2 i PIY2, zawierające posortowane indeksy Codsyłacze} do rekordów symboli odpowiednio według współrzędnej X1,Y1,X2,Y2 obrysu prostokątnego symbolu. Ten bardziej wyrafinowany algorytm umożliwia przyspieszenie wyszukiwania odpowiednich rekordów celem wyświetlenia na ekran według atrybutu kolejności wprowadzania do pliku PZ. Pozwoli to na uniknięcie niejednoznaczności przy częściowym lub całkowitym nakładaniu się na siebie obiektów. Zatem odtworzenie dokładne obrazu mapy będzie zgodne z intencjami budującego mapę i jednocześnie stosunkowo szybkie, przy zmniejszonej zajętości pamięci Cpliki lub tablice indeksowe mogą być tworzone na bieżąco}.

Można przyjąć, że rekord źródłowy dla takiego wariantu będzie miał następującą budowę :

Typ XI Yl X2 *Y2 K LS i nne parametry gdzie: K - kolejność wprowadzenia do pliku PZ,

LS - liczba słów w rekordzie Czmienna pomocnicza}, pozostałe oznaczenia, jak wyżej.

Warunek przynależności obiektu do ekranu bieżącego zilustrowano na rys. 2.

VCCX1 X2 eCXP.XKl}yvCY2 eCYP,oo]}} VCCY1 ^ Y2 e C YP. YK3 }ysCX2 « CXP,od]}}v VCCX1 *€CO,XP]} ^ CY1 eC O, YP]} /s CX2 eCXK.oo]} ^ CY2 eCYK.ool}} * wyświ et1 ani e .

Obraz na ekranie budowany jest na podstawie przeliczenia:

X e C XP,XK] — ♦ X , e i O,GetmaxX 3 ekr

Y e CYP.YK] — ♦ Y . e C0,GetmaxY3 ekr

gdzie GetmaxX i GetmaxY oznaczają rozdzielczość ekranu Cliczbę punktów

<pixeli>} odpowiednio dla X i Y. Przesuw obrazu polega na nadaniu nowych wartości XP * X P ’. YP * Y P ’ , XK * X K ’ i YK 4 Y K ’ bez zmiany wartości różnic XK - XP i YK - YP. Przeskalowanie obrazu polega na zmianie wartości różnić XK - XP i YK - YP.

Po przeskalowaniu nastąpi przeliczenie obrazu:

X ’ e C X P * ,XK* 3 ę X . e [O,GetmaxX3 ekr

Y ’ e CYP’,YK’3 + Y . e C0.GetmaxY3 ekr

Powiększenie różnicy XK - XP i YK - YP umożliwia ulokowanie na ekranie więcej szczegółów mąpy przy jednoczesnym •’zmniejszeniu” obrazu.

Wykorzystanie pomocniczej tablicy TR w rozpatrywanym wariancie może

(10)

156 Roman Konieczny

0,0

Yi

Y 2

Y1 X1

Y2

Y2

1 ■

Y 1

X 1 X 2

k

*

r

X 2 .

X P E M M

Y 1

X K

I

i Y P

!

Ł -

_ . , .

I I

1 I

3 r

Y 2

I L

Y 2

--------------!

} _

X I

XI XL

Rys.2. Ilustracja problemu przynależności obiektu do ekranu Fig.2. A problem illustration of ebject affiliation to screen

być zorganizowane poprzez określenie pozaekranowego obszaru penetracji mapy Crys.33* limitowanego tylko rozmiarem tej tablicy.

0.0 maxX

ek r an

obs: ar penetracji zawartość tablicy TR MAPA Czawartość pliku P2D

Y maxY

Rys. 3. Wyjaśnienie określenia "obszar penetracji mapy"

Fig. 3. An explaining of "map penetration area" term

(11)

Niektóre aspekty rozwoju modułu MAPA.

Odpowiednie rekordy mogą być przepisane do TR według wskazań plik. w indeksowych PIX1„ P I Y 1 , PIX2 i PIY2. Gdy ekran dojdzie do któregoś z brzegów obszaru penetracji, można wtedy określić nowy zakres tego obszaru i zaktualizować tablicę TR. Przedstawione rozwiązanie również umożliwia płynne “chodzenie" po dowolnej płaskiej mapie bez względu na rozmieszczenie skupisk szczegółów.

Struktura pliku indeksowego jest prosta. Podstawowymi elementami tego pliku są pary < współrzędna: XI Y1 v X2 v Y2, indeks C odsyłacz}*. Oprócz podstawowych plików indeksowych mogą być również utworzone pomocnicze pliki indeksowe zawierające wyłącznie odsyłacze dla wybranych symboli na mapie. np. dla mapy kolejowej: semaforów, głowic, połączeń itd.

Uzupełniając rozważania dotyczące rozwoju modułu MAPA należy wspomhieć Jeszcze o trzech aspektach:

- edycji symboli.

- umieszczaniu symboli.

- wyszukiwaniu symboli.

Symbole mogą być podzielone na trzy grupy:

- elementarne Cnp. okrąg» odcinek, prostokąt... z repertuaru biblioteki graficznej Turbo PASCAL-a są spiine, wielobok. . . z biblioteki użytkownika},

- podstawowe Cskładające się z symboli elementarnych, np. semafor, czv połączenie na mapie kolejowej},

- z ł o ż o n e Cskładające się z symboli podstawowych ewentualnie uzupełnione symbolami elementarnymi, np. grupa torów, stacja, głowica}.

Symbol można tworzyć na bazie fontu kreskowego Cwektorowego} lub punktowego Cmatr yeowego} względnie obu naraz. Opcje budowy symboli nie powinny odbiegać od znanych w tym zakresie standardów. Powinny uwzględniać obsługę

"myszy", rozwijałne menu, względnie sterowanie ikonami. Powinny dawać możliwość określania rozmiarów symbolu Cpowiększanie, obrót itd.} oraz dawać możliwość modyfikacji jego parametrów. Utworzone symbole powinny być gromadzone w pliku bibliotecznym.

Przy umieszczaniu symboli na mapie powinna być możliwość: wyświetlania pomocniczego fragmentu siatki współrzędnych, przesuwu symbolu, obrotu, modyfikacji, a także kopiowania względnie usuwania. Można także przewidzieć opcję automatycznego rozmieszczania symboli, a w dalszej przyszłości możliwość generowania różnych wariantów map względnie ich fragmentów.

Opcja wyszukiwania, na podstawie pomocniczych plików indeksowych, powinna umożliwiać odnalezienie symbolu dowolnego typu na mapie, a także dokonanie zestawienia CstatystykiD symboli, wyszukiwania grup symboli itd.

(12)

158 Roman Koni ecz ny

4. Uwagi końcowe

Tworząc nowe projekty rozwojowe modułu MAPA należy ciągle mieć na względzie istniejący ustawiczny duży postęp w tego typu standardowym profesjonalnym oprogramowaniu. Idee i koncepcje rozszerzenia modułu MAPA nie powinny być nigdy wtórne, a jedynie nawiązujące do najlepszych rozwiązań światowych w tym zakresie C względnie je wycinkowo wzbogacająceD,przy uwzględnieniu realności krajowych potrzeb oraz możliwości zastosowań.

Jak pokazały dotychczasowe doświadczenia z modułem programowym MAPA, a także inne eksperymenty programowe, przeprowadzone w Instytucie Transportu Politechniki Śląskiej, w zakresie podstawowym, t j . wyszukiwania symboli i budowy obrazu, osiągnięto rezultaty porównywalne Ca nawet nieco korzystniejsze!) w stosunku do takich standardów, jak AutoCAD czy OrCAD.

Natomiast z punktu widzenia przyszłego użytkownika przedstawione oprogramowanie jest znacznie tańsze, nie podlega licencji i jest łatwiejsze do adaptacji pod kątem wybranych zastosowań.

LITERAJURA

Cl] - KONIECZNY R. z zespołem Cpraca zbiorowa}-. Opracowanie koncepcji makroskopowego modelu symulacyjnego ruchu pociągów. Katowice 1986 Cmaszynopis pracy naukowo-badawczej wykonanej w Instytucie Transportu Politechniki Śląskiej w ramiach programu RP.I.09}

[23 - KONIECZNY R.z zespołem Cpraca zbiorowa}: Zastosowanie jeżyka LOGLAN do modelowania dużych systemów transportowych na przykładzie modelu ruchu pociągów. Katowice 1987 Cmaszynopis pracy naukowo-badawczej wykonanej w Instytucie Transportu Politechniki Śląskiej w ramach programu RP.I.09}.

13] - KONIECZNY R.z zespołem Cpraca zbiorowa}: Zastosowanie języka LOGLAN do modelowania dużych systemów transportowych na przykładzie modelu ruchu pociągów - etap II. Katowice 1988 Cmaszynopis pracy naukowo-badawczej wykonanej w Instytucie Transportu Politechniki Śląskiej w ramach programu RP.I.09}.

[4} - KONIECZNY R. z zespołem Cpraca zbiorowa}-. Zastosowanie języka LOGLAN do modelowania dużych systemów transportowych na przykładzie modelu ruchu pociągów - etap III. Katowice 1989 Cmaszynopis pracy naukowo-badawczej wykonanej w Instytucie Transportu Politechniki Śląskiej w rabach programu RP.I.09}.

C53 - KONIECZNY R: Charakterystyka zasobów symulacyjnych języka LOGLAN na potrzeby modelowania systemów transportowych. Zeszyt Naukowy Politechniki Śląskiej, s. Transport nr 9, Gliwice 1989 cz. I i II.

C63 - KONIECZNY R. : Zasoby symulacyjne języka LOGLAN. Zeszyt Naukowy Politechniki Śląskiej, s. Transport nr 13, Gliwice 1389.

C7] - KONIECZNY R: Przykłady rozwiązania problemów symulacyjnych w języku LOGLAN. Zeszyt Naukowy Politechniki Śląskiej, s. Transport nr 13.

Gliwice 1989.

C8] - KONIECZNY R. : Zagadnienie rozszerzenia loęianowskich zasobów symulacyjnych. Zeszyt Naukowy Politechniki Śląskiej, s. Transport nr 13 Gliwice 1989.

(13)

Niektóre aspekty rozwoju modułu MAPA. 159

SOME ASPECTS OF MAPA MODULE DEVELOPMENT FOP RAILWAY TRAFFIC SIMULATION

Summary

MAPA programme module is a part of railway traffic simulator and it vizualizes simulation data on topographic map of the selected railway system area.

Research on computer railway traffic simulator has been carried out at the Institute of Transport of the Silesian Technical University since 1986 by order of the Institute of Computer Science at Warsaw University. This is a part of RP.I.09 project C"Languages, methods and development of methods and formal basic software"}. The paper contains general account of simulator's software and MAPA module present version in particular. There are also some suggestions on further rationalization and development of the module.

EINIGE ENTWICKLUNGSASPEKTE DES MAPA-PROGRAMMODULS FÜRDEN ZUGVERKEHRSSIMULATOR

Zusammenf assung

Das MAPA - Programmodul stellt ein Bestandteil des Zugverkehrssimulators dar. Die Aufgabe des Moduls besteht in der Visualisierung von Simulationsergebnissen auf der topologischen Karte ausgewähltes Bahnnetzregions. Die Forschungsarbeiten, die mit der Realisierung des Zugverkehrssimulators auf dem Rechner verbunden sind, laufen im Transport-Institut der Schlesischen Technischen Universität seit 1936. Sie werden im Auftrag des Informatik-Insti tutes der Warschauer Universität im Rahmen des Forschungsprogramms Nr. RP.I.09: "Entwicklung von Sprachen, Methoden sowie formalen Grundlagen der Software". Der Aufsatz beinhaltet in gekürzter Fassung die Besprechung der Simulatorsoftwäre, unter der besonderen Berücksichtigung aktueller Version des MAPA - Moduls.

Im weiteren hat er ausgewählte Sugestionen bezüglich der weiteren Entwicklung und Vervol1kommunung dieses Moduls zum Inhalt.

(14)

160 Roman Konieczny

HEK0T0PHE 0C05EHH0CTM PA3BMTHH MOflYJIfl MAPA HEOBXOflMMOE MOZIEJIMPOBAHMfl

¿IBMXEHWfl n0E320B

Pea»Me

ilporpaiiMHasi n o/iyjib MAPA H B J i a e T C S c o c T a B J i s n o w e i i noziejiM A B H x e i i M H ^ n o e3, / i o b K O T D p a a H « e e r C B o e r t uejibto r r p o w H p O B a H M e p e a y j i b T a T O B rco/iejiMpOBaHMSi H a T o n o j i o r w M e c K O H K a p T e p a w o H a a c e j i e a H O f l o p o x H o f t c e m . P a ó o i b ł c b sj 3 a H H b i e c K o r i m o T e p H O M p e a j i H 3 a u n e ń K o / i e n H nb h k s i T T o e s a o B B e a y T c a H a Ka<t>eape T p a H c n o p r a C m ie3C K oro I l o J i M T e x H H M e c K o r o WHCTHTyTa c 1 9 8 6 ro zia no 3 a > c a 3 y Kadi e / i p H M H < j > o p M a T H K H B a p i o a B C K o r o Y H H B e p c H T e T a k s k M a c T b rrporpatiMbi R P . I . 0 9

" P a 3 E H T H e B 3 b l K O B , M e T O / I O B H 'JiOptia Ufa H MX O C H O B T T p o r p a i l H M p O B 3 H H S I **. B C T d T b M n o M e i u e H o c o K p a u ^ K H o e o r m c a H M e B c e x n p o r p a M M n e a e j i H c o c o 6 h m m y i e T O M a K T y a j i H o r o & ap n an T a no/iyjiM MAPA.

Goaepjurr ona Taxxe HsópawHue Trpe-anojioxeHHss KacaiouiMecsi 6onbMeftiDero p a 3 B K T M S 3 T O H MOZfyJlM.

Cytaty

Powiązane dokumenty

CTaTfaa siBJisieTcsi ochobo A ajis oopnajibHoro otthc a hüb no/re jih b KOHBeHllHH OTTHC 3HM CMCTSMisl fl.HCKpeXHblX

Opis n ie

Prezentacja ogćlna modelu... Prezentacja ogólna

[r]

Streszczeni e. W artykule przedstawiono dwukomputerową wersją makromodelu ruchu pociągów, której celem jest między innymi graficzna prezentacja stanu modelu

Str iszczenie. Przy realizacji symulatora ruchu pociągów przyjęto ogólną koncepcję, że wyniki symulacji wizualizowane będą przy pomocy modułu wyświetlającego

Zgodnie z tym co przedstawiono dotychczas dla potrzeb modelu ruchu pociągów na linii KRR. Obiekty topologiczne w modelu ruchu pociągów na linii KRR Fig.17..

Dla celów tych zdefiniowano strukturę opisu dyskretnego topologii rejonu sieci oraz zbiór macierzy pojemności regulacyjnych rejonu sieci.. THE STRUCTURE OF A DISCRETE