Embed Size (px)
Citation preview
i
UNIVERZITET U NOVOM SADU
FAKULTET TEHNI^KIH NAUKA
ELEKTROTEHNI^KI ODSEK
INSTITUT ZA RA^UNARSTVO I AUTOMATIKU
KATEDRA ZA RA^UNARSKU TEHNIKU I KOMUNIKACIJE
@eljko Jurca
PRISTUP AUTOMATIZACIJI DIREKTNOG PRA]ENJA ISPRAVNOSTI PROGRAMSKE PODR[KE U REALNOM
VREMENU
- MAGISTARSKA TEZA -
Novi Sad, 1999. godine
ii
Navesti svakog ko je doprineo da se rad na ovoj magistarskoj tezi privede kraju krije opasnost da se neko ime zaboravi, ili da ne bude postavljeno na zaslu`eno mesto. Stoga }u se ograni~iti samo na ona imena koja se ne mogu izostaviti.
Nedovoljno je re}i da najve}u zahvalnost dugujem prof. dr Vladimiru Kova~evi}u, po{to ovog rada ne bi uop{te ni bilo da nije njegove bezgrani~ne upornosti i koji me je vodio i usmeravao u svim fazama izrade ove teze. Tako|e mi je od neprocenjive pomo}i bila podr{ka prof. dr. Miroslava Popovi}a, a posebno njegove smernice u zavr{noj etapi rada. Naro~itu zahvalnost dugujem prof. dr. Slavku Svir~evi}u {to me je uveo u problematiku teorije saobra}aja, kao i za korisne primedbe na uobli~avanju zavr{nog teksta. Svim ~lanovima Komisije, koji su od samog po~etka pratili tok izrade teze, se zahvaljujem na korisnim diskusijama i sugestijama koje su doprinele da ona bude jasnija i preglednija.
iii
SADR@AJ UVOD ...........................................................................................................iv 1. OP[TI PRIKAZ OBJEKTA RAZMATRANJA .......................................1 1.1. Koncept otvorenih sistema .............................................................................1 1.2. Uporedni model ..............................................................................................5 1.3. Konfiguracija za ispitivanje ............................................................................7 2. SDL - JEZIK ZA SPECIFIKACIJU I OPISIVANJE ................................8 2.1. Karakteristike SDL jezika ...............................................................................9 3. METODOLOGIJA ISPITIVANJA USAGLA[ENOSTI PROGRAMSKE PODR[KE SA PREPORUKAMA ........................14 3.1. Ciljevi ispitivanja usagla{enosti ...............................................................15 3.2 Metode ispitivanja ....................................................................................17 3.3 Primena metode ispitivanja .......................................................................20 4. PROGRAMSKA PODR[KA ZA MODIFIKOVANJE IZVORNOG C-KODA I SDL DIJAGRAMA .........................................................23 4.1. ON-LINE modifikacija .................................................................................25 4.2. OFF-LINE modifikacija ................................................................................30 4.3. Ubacivanje programskog koda ......................................................................30 4.4. Koncepcija programske podr{ke za modifikovanje izvornog C-koda i SDL dijagrama ..........................................................................................30 5. OSNOVNI POJMOVI TEORIJE SAOBRA]AJA I JEDNO RE[ENJE REALIZACIJE PRIKUPLJANJA SAOBRA]AJNIH PODATAKA .........33 5.1. Osnovni pojmovi teorije saobra}aja ..............................................................33 5.1.1.Sistemi signalizacije ................................................................................................38 5.2.Programska podr{ka za merenje saobra}aja i prikupljanje statisti~kih podataka .............................................................................................41 5.2.1.Merenje saobra}aja na perifernim organima ..........................................................43 5.2.2.Merenje signalnog saobra}aja ...............................................................................46 5.2.3.Prikupljanje statisti~kih podataka ..........................................................................47
6. PERFORMANSA KOMUTACIONOG URE\AJA ...............................48 6.1. Performansa obrade poziva za vreme preoptere}enja ..............................49 6.1.1. Projektovani kapacitet komutacionog ure|aja ..................................................50
iv
6.2. Za{tita od preoptere}enja ..............................................................................50 6.3. Metodologije za merenje kapaciteta centralnog procesora komutacionog ure|aja ......................................................................................................54 6.4. Indikatori performanse ..................................................................................57 6.5. Realizacija predlo`ene metode merenja optere}enja procesora ....................59 6.6. Jedan primer realizacije metode merenja optere}enja procesoa ...................64 7. ZAKLJU^AK ..........................................................................................72 7.1. Pregled rezultata istra`ivanja .........................................................................72 7.2. Mogu}i pravci daljih istra`ivanja ...................................................................74 Kori{}ena literatura ......................................................................................75 PRILOG 1 ....................................................................................................79 PRILOG 2 ....................................................................................................96
v
Uvodno poglavlje
UVOD
Realizacija slo`enog sistema kao {to je programska podr{ka koja treba da radi u realnom vremenu se metodolo{ki mo`e grubo podeliti u nekoliko faza. Prva faza je projektovanje, zatim sledi njegovo primenjivanje i na kraju pode{avanje performansi, kao i odr`avanje sistema. Radi provere postavljenih ciljeva iz svake faze neophodno je sprovesti ispitivanja kojima se potvr|uje ispravnost do tada ura|enog posla. Metodologija sprovo|enja ovih ispitivanja je centralni problem koji }e se razmatrati u ovom radu.
Cilj ovog magistarskog rada je razrada metoda za pra}enje ispravnosti rada programske podr{ke na primeru upravljanja komutacionim ure|ajima (centralama) pod raznim uslovima njihovog saobra}ajnog optere}enja.
Te`i{te ispitivanja u ovom radu je skoncentrisano na ispitivanje performanse upravlja~kog dela komutacionih ure|aja, jer se {tite}i sistem od preoptere}enja {titi i ispravnost rada programske podr{ke u {irem smislu. Ispravnost rada programske podr{ke se {titi time {to se dr`i pod kontrolom optere}enje najvitalnijeg organa u komutacionom ure|aju. Naime, ispravnost programske podr{ke je funkcija optere}enja, po{to se u uslovima preoptere}enja ona mo`e na}i u neregularnim re`imima rada. Na taj na~in se uvidom u kvantitativnu meru stepena optere}enja dolazi do informacija o ispravnosti rada programske podr{ke. S obzirom da se pomo}u saobra}ajnih karakteristika i statisti~kih parametara pokazuje osnovna funkcija komutacionog ure|aja, neophodno je prikupiti te podatke. Da bi se do svih pomenutih podataka do{lo, neophodno je obaviti merenja na samom objektu (komutacionom ure|aju). U procesu implementacije takvih merenja korisno je imati pogodan alat za modifikaciju programskog modela. Takav alat je razvijen i on koristi izvorni kod u C jeziku i SDL dijagrame.
Programska podr{ka koja treba da radi u realnom vremenu pretpostavlja specifi~ne postupke koji proisti~u iz posebnih uslova u kojima ovakvi programi rade. Ispitivanje ispravnosti se najve}im delom zasniva na proveri usagla{enosti realizovane podr{ke sa referentim specifikacijama, kao i na ispitivanju performanse.
vi
Naj~e{}i na~in verifikacije realizovane programske podr{ke se sastoji u pra}enju pona{anja ra~unarskog sistema za datu pobudu. Verifikacija se zasniva na mnogim elementima, a svi se mogu svrstati u dve glavne grupe:
• kriterijumi vezani za ispitivanje usagla{enosti realizovane implementacije sa referentnim preporukama i
• kriterijumi vezani za projektovanu efikasnost rada
Prva grupa kriterijuma defini{e parametre pomo}u kojih se ispituje ispravnost rada, odnosno da li se za pretpostavljenu pobudu dobija o~ekivani odziv. Ovim postupcima se porede elementi skupa izlaznih parametara sa pretpostavljenim izlaznim parametrima, za dat skup ulaznih parametara ne uzimaju}i u obzir vremensku komponentu.
Druga grupa kriterijuma defini{e parametre koji nadogra|uju prvu grupu tako {to se uvodi zahtev da se `eljeni odziv realizuje u strogo definisanim vremenskim okvirima. Time se ocenjuje efikasnost, odnosno performansa ispitivanog sistema.
Rad sadr`i slede}a poglavlja:
1. Teorijske osnove rada
2. SDL - jezik za specifikaciju i opisivanje
3. Metodologija ispitivanja usagla{enosti programske podr{ke sa preporukama
4. Programska podr{ka za modifikovanje izvornog C-koda i SDL dijagrama
5. Jedno re{enje realizacije prikupljanja saobra}ajnih podataka komutacionog ure|aja
6. Performansa komutacionog ure|aja
7. Zaklju~ak
U prvom poglavlju se daju osnovne postavke koncepta otvorenih sistema zato {to je programska podr{ka koja se ispituje deo jedne primene pomenutih koncepata. Tako|e je izlo`en i uporedni model kao prakti~na realizacija specifikacija koje slu`e kao referenca u procesu ispitivanja. Ova prakti~na realizacija se zasniva na SDL dijagramima. Na kraju ovog poglavlja su opisane konfiguracije za ispitivanje sa osvrtom na dobre strane svake od njih.
U drugom poglavlju je opisana koncepcija SDL jezika zbog njegove va`nosti u definisanju uporednog modela.
U tre}em poglavlju je izlo`ena koncepcija metodologije ispitivanja u okviru gore pomenute prve grupe kriterijuma, tj. usagla{avanja sa preporukama.
U ~etvrtom poglavlju je izlo`en primer realizacije programskog alata za pretvaranje izvornog teksta C jezika u SDL dijagrame. Ovim programskim sredstvom se
vii
mo`e modifikovati tako dobijeni SDL dijagram, ~ime se na jednostavan na~in u izvorni program ubacuju ranije pripremljene funkcije vezane za proces ispitivanja. Ovako se izbegava postojanje vi{e verzija jednog te istog programa. Za svaki test se uzme originalni program, pa se on modifikuje tako da se dobije uvid u merene veli~ine. Naj~e{}e je ta modifikacija dodavanje sprega za o~itavanje izlaznih veli~ina.
U petom poglavlju je prikazan primer prakti~ne realizacije programske podr{ke vezane za saobra}ajne parametre komutacionog ure|aja.
U {estom poglavlju je opisana metodologija ocenjivanja efikasnosti programske podr{ke za telefonsku komutaciju i dat je prakti~ni primer za realizaciju izra~unavanja optere}enja procesora kao najboljeg predstavnika za indikator performanse.
Poslednje, sedmo poglavlje obuhvata zavr{na razmatranja i opis glavnih rezultata navedenih po poglavljima, kao i pogled na mogu}e pravce daljeg rada na problemu automatizacije direktnog pra}enja ispravnosti programske podr{ke u realnom vremenu.
1
Poglavlje 1
1. OP[TI PRIKAZ OBJEKTA RAZMATRANJA
Izgradnja telekomunikacionih sistema, ~iji je upravlja~ki deo ra~unarski sistem ~ija programska podr{ka radi u realnom vremenu, podrazumeva niz postupaka me|u koje spadaju i projektovanje i izrada te programske podr{ke. Programska podr{ka za ove sisteme treba da zadovolji mnoge uslove, me|u kojima su i slede}i:
• da radi u realnom vremenu,
• da bude robusna,
• da bude otvorena za razne vrste promena tokom kori{}enja
• da obezbedi visok stepen iskori{}enja resursa, naro~ito onih koji su vitalni za rad celog sistema
Zna~ajna etapa u procesu izgradnje programske podr{ke je ispitivanje njene ispravnosti. Naime, postavlja se pitanje da li su realizovani programi u skladu sa projektovanim zahtevima. Da bi se do{lo do odgovora na ta pitanja koriste se razli~iti postupci. Neki od tih postupaka implicitno daju odgovore, dok neki daju eksplicitne odgovore. U prvu grupu postupaka spadaju ispitivanja funkcionalnosti sistema. Dakle, o ispravnosti rada programske podr{ke se posredno zaklju~uje na osnovu toga da li ona pru`a korisniku sve usluge koje se od nje zahtevaju. U eksplicitne postupke spadaju ispitivanja ispravnosti rada sistema zasnovana na precizno definisanim testovima.
1.1. Koncept otvorenih sistema
Mogu}nost me|usobnog komuniciranja geografski udaljenih ra~unarskih sistema predstavlja jednu od najva`nijih karakteristika koju ovi sistemi treba da poseduju. Informacije se razmenjuju preko telekomunikacionih mre`a pogodnih za prenos glasa, podataka ili slika [1]. Mre`a se defini{e kao skup fizi~kih ~vorova i prenosnih puteva za prenos i obradu informacija. Komuniciraju}i ra~unarski sistemi, ma kako raznorodni bili,
2
oslanjaju se na sredstva za prenos podataka, tj. mre`ne strukture koje mogu da variraju od javnih telefonskih do privatnih LAN mre`a. Mre`na struktura slu`i kao osnova projektovanja koje objedinjuje elemente fizi~ke arhitekture i programske podr{ke tako da ti elementi uobli~avaju logi~ke nivoe upravljanja mre`om. Nezavisno od vrste prenosnog sistema, neophodno je anga`ovanje dela resursa fizi~ke arhitekture i programske podr{ke radi rukovanja odgovaraju}im strogo definisanim procedurama u okviru kojih se razmenjuju poruke izme|u dva entiteta. Ove procedure se nazivaju protokoli. Na primer, oni su odgovorni za uspostavu komunikacionog kanala u mre`i i za upravljanje tokom poruka du` tog kanala kao i raskidanje uspostavljene veze. Zahteve za ove procedure diktira mre`no okru`enje. Me|utim, de{ava se da se zahtevi za istu logi~ku celinu veoma razlikuju na svakoj od komuniciraju}ih strana, po{to su te strane raznorodni ra~unarski sistemi. To zna~i da oni mogu da koriste razli~ite programske jezike i {to je jo{ va`nije, razli~ite oblike prikazivanja podataka. Tako|e, ra~unari mogu da koriste razli~ite operativne sisteme. Stoga se mogu imati sasvim razli~ite sprege izme|u korisni~kih programa, tj. aplikativnih procesa i komunikacionih usluga.
U ranom periodu ra~unarskih komunikacija ove situacije su dovodile do toga da su me|usobno efikasno mogle komunicirati samo zatvorene zajednice istorodnih ra~unara, kao {to su bile mre`e velikih proizvo|a~a ra~unara. Ove mre`e nisu posedovale mogu}nosti povezivanja sa mre`ama druga~ijeg tipa, odnosno nisu bile otvorene za povezivanje. Da bi se prevazi{ao ovaj problem, Me|unarodna organizacija za standarde (engl., International Standard Organization - ISO) je kasnih 1970-tih godina formulisala referentni model da bi se dobila zajedni~ka osnova za koordinaciju razvoja standarda i da bi se omogu}ilo postoje}im re{enjima da se me|usobno uklope. Krajnja namera je bila da se omogu}i aplikativnim procesima u bilo kom ra~unaru koji podr`ava primenjene standarde da slobodno komunicira sa aplikativnim procesima u bilo kom drugom ra~unarskom sistemu koji tako|e podr`ava iste standarde, nezavisno od njegovog proizvo|a~a. Ovakav model je nazvan ISO Referenti model za povezivanje otvorenih sistema. Treba naglasiti da se ovaj model ne bavi specifi~nim aplikacijama za ra~unarske komunikacione mre`e. Umesto toga, on se bavi strukturiranjem komunikacione programske podr{ke koja je neophodna da bi se imale pouzdane i transparentne komunikacione usluge kao podr{ka {irokom spektru aplikacija.
Komunikacioni podsistem se bazira na slo`enoj programskoj podr{ci. Raniji poku{aji implementacije takve programske podr{ke su ~esto bili zasnovani na jednom kompleksnom, nestrukturiranom programu, ~esto napisanom na asemblerskom jeziku, koji je bio u sprezi sa mnogim drugim komponentama. Rezultuju}i komunikacioni podsistem je tako bio te`ak za ispitivanje, a naro~ito za promene.
Da bi prevazi{la ove manjkavosti, ISO je usvojila slojeviti pristup za referentni model. Celokupni komunikacioni podsistem je razlo`en na ve}i broj slojeva od kojih svaki izvodi jasno definisane funkcije. Ovi slojevi ili nivoi su zadu`eni za dve vrste funkcija:
• funkcije u`e vezane za komunikacionu mre`u i
• aplikaciono orjentisane funkcije
Ovakva podela dovodi do toga da se mogu uo~iti tri razli~ita radna okru`enja (vidi se na slici 1.1.):
3
• mre`no okru`enje, zadu`eno za protokole i standarde koji se ti~u razli~itih tipova komunikacionih mre`a,
• okru`enje otvorenih sistema, koje objedinjuje mre`no okru`enje sa dodatnim aplikativno orjentisanim protokolima i standardima {to omogu}ava krajnjim sistemima da me|usobno komuniciraju na otvoren na~in i
• okru`enje realnog sistema izgra|eno na okru`enju otvorenih sistema ~ijom se izgradnjom zadovoljavaju zadaci distribuirane obrade informacija kod krajnjeg korisnika.
Komponente OSI modela, kako one koje su zavisne od mre`e, tako i aplikaciono orjentisane (nezavisne od mre`e), su izgra|ene u obliku protokola sa vi{e nivoa. Granice izme|u svakog nivoa protokola, i prema tome funkcije koje obavlja svaki od tih nivoa, su izabrane kao rezultat iskustava iz ranijeg perioda izgradnje standarda.
Ra~unar A Ra~unar B
Okru`enje realnog sistema
Okru`enje otvorenih sistema
Mre`no okru`enje
Korisni~ki proces
Aplikativnefunkcije
Mre`ne funkcije
Korisni~ki proces
Aplikativnefunkcije
Mre`ne funkcije
Prenosni medijum
Slika 1.1. Razli~ita okru`enja komuniciraju}ih sistema
Svaki nivo obavlja precizno definisane funkcije u kontekstu sveobuhvatne komunikacione strategije. Nivo radi saglasno definisanom protokolu putem razmene poruka, kako korisni~kih podataka, tako i dodatnih upravlja~kih informacija sa korespodentim nivoom u udaljenom sistemu. Svaki nivo poseduje ta~no utvr|enu spregu izme|u njega i prvih nivoa iznad i ispod njega, a kao rezultat primene odre|enog protokola nivo je nezavisan od drugih nivoa.
Logi~ka struktura referentnih ISO nivoa je prikazana na slici 1.2.
4
Slika 1.2. Struktura ISO referentnog modela
Kao {to se vidi, referentni model je izgra|en od sedam nivoa. Tri najni`a nivoa (obele`ena brojevima od 1 do 3) su zavisna od mre`e i zadu`ena su za protokole koji su pridru`eni samoj mre`i za prenos podataka koja se koristi za fizi~ko povezivanje ra~unarskih sistema. Nasuprot njima, tri gornja nivoa (obele`ena brojevima od 5 do 7) su aplikaciono orjentisani i zadu`eni su za protokole koji omogu}avaju da dva krajnja korisnika aplikativnih procesa me|usobno korespondiraju, preko niza usluga koje im nudi lokalni operativni sistem. Sredi{nji, transportni nivo osloba|a vi{e aplikativne nivoe detaljnih operacija ni`ih nivoa zavisnih od mre`e.
Funkcija svakog nivoa je definisana na formalan na~in u obliku protokola koji odre|uje skup pravila i konvencija koje koriste nivoi da bi komunicirali sa sebi ravnim, tj. kooperiraju}im nivoom u drugom, udaljenom sistemu. Svaki nivo obezbe|uje odre|eni skup usluga nivou koji je prvi iznad njega, i sa druge strane, koristi usluge obezbe|ene od nivoa koji je prvi ispod njega za prenos poruke pridru`ene protokolu prema udaljenom kooperiraju}em nivou. Tako se formiraju dva toka informacija. Jedan tok je logi~ki, horizontalni tok razmene informacija izme|u kooperiraju}ih procesa, a drugi je fizi~ki, vertikalni tok preko ~vorova preseka na mestima sprege dva susedna nivoa.
Svaki nivo u modelu se deli na objekte, ili entitete, a svaki objekat je predstavljen skupom funkcija koje su me|usobno povezane zajedni~kim ciljem funkcionisanja. Na svakom nivou mo`e biti jedan ili vi{e protokola i svaki objekat mo`e koristiti proizvoljan broj protokola. Ta~ke me|usobnog delovanja izme|u susednih nivoa se nazivaju presekom ili pristupom poslu`ivanju, tj. oni komuniciraju preko ~vorova preseka. Informacija koja se prenosi izme|u objekata, prenosi se u obliku blokova koji formiraju tzv. okvire, u
Ra~unar A Ra~unar B
Aplikacioni nivo
Prilagodni nivo
Nivo uspostave komunikacije
Transportni nivo
Mre`ni nivo
Nivo kanala
Fizi~ki nivo
Aplikacioni nivo
Prilagodni nivo
Nivo uspostave komunikacije
Transportni nivo
Mre`ni nivo
Nivo kanala
Fizi~ki nivo
Mre`a za prenos
5
kojima je poruka koja se prenosi i dodatne kontrolne informacije, sme{tene u zaglavlje i za~elje okvira. Ovi blokovi, tj. okviri se nazivaju protokolske jedinice podataka (engl., Protocol Data Unit - PDU).
Programsku podr{ku za svaki od nivoa defini{e specifikacija protokola koju ~ini:
• Kvalitativni opis tipova protokolskih jedinica podataka pridru`enih objektu protokola i njihovoj ulozi, zajedno sa opisom polja prisutnih u svakoj jedinici podataka i njihova upotreba.
• Opis procedura za razne faze rada objekata protokola i usluge koje koristi za prenos svakog tipa jedinice podataka.
• Formalna definicija strukture svakog tipa jedinice podataka.
• Precizna definicija rada entiteta protokola u jednom od oblika formalne specifikacije.
Dva korespodentna entiteta komuniciraju razmenjuju}i poruke, tj. protokolske jedinice podataka (PDU). Jedinica podataka sadr`i informacione i upravlja~ke podatke. Upravlja~ke podatke protokola generi{e sam nivo, tj. entitet protokola. Po{to parametri pridru`eni uslu`nim porukama imaju samo lokalno zna~enje, oni se defini{u kao apstraktni tipovi podataka. Nasuprot tome, jedinice podataka koje generi{u entiteti protokola se prosle|uju izme|u dva sistema i stoga, da bi bili jednozna~ni, oni se moraju definisati na precizan na~in tako da imaju za oba sistema zajedni~ko zna~enje. Da bi se ovo ostvarilo, jedinice podataka pridru`ene entitetima protokola se defini{u u dokumentima standarda na precizan na~in tako da se formuli{u u notaciji apstraktnih tipova podataka. Ova notacija je poznata pod imenom "Apstraktna sintaksna notacija broj jedan" (engl., Abstract Syntax Notation Number One - ASN.1). Deo ove notacije ~ini i "Skup pravila kodiranja".
Koncept otvorenih sistema, tj. OSI model se mo`e koristiti kao referentni model bilo koje mre`e. Stoga }e ovaj koncept, tj. model biti upotrebljen kao referentni model u procesu definisanja uporednog modela.
1.2. Uporedni model
Svakom nivou komuniciranja je pridru`en skup poruka koje obezbe|uju poslu`ivanje, kao {to je npr. uspostava veze, prenos podataka, raskidanje veze i sl. Po prijemu uslu`ne poruke na mestu sprege nivoa potrebno je najpre odrediti da li je poruka do{la u dozvoljenom redosledu. Zbog toga se u standardu defini{e dozvoljeni redosled uslu`nih poruka za taj nivo, na nekom od formalizovanih oblika prikazivanja [2].
Ovakve specifikacije protokola se koriste iz slede}ih razloga:
• Za svaki protokol obi~no postoji jedna specifikacija koja slu`i kao "referenca" za sve ostale aktivnosti.
6
• Specifikacije protokola se koriste za proveru projektovanja protokola datog nivoa. U tom cilju, poslu`ivanje koje pru`a objekat protokola komuniciraju}i preko poslu`ivanja podre|enog nivoa se poredi sa poslu`ivanjem definisanim u specifikaciji datog nivoa.
• Specifikacija protokola se koristi za razradu implementacije
• Specifikacija protokola se koristi za vreme ispitivanja i otklanjanja gre{aka u implementaciji.
Jedan primer standardizacije formalizovanog oblika specificiranja predstavlja tzv. jezik za specificiranje i opisivanje (engl., Specification and Description Language - SDL). SDL se zasniva na modelu automata sa kona~nim brojem stanja [3]. Po{to je protokol mogu}e opisati kao automat sa kona~nim brojem stanja mo`e se predstaviti na jedan od slede}ih na~ina:
• pomo}u tabela ulaza, prelaza i izlaza,
• pomo}u grafa prelaza stanja,
• pomo}u SDL dijagrama.
SDL objedinjuje prva dva na~ina prikazivanja. Na taj na~in ovi SDL dijagrami opisuju logi~ku strukturu programa, njegov dinami~ki tok, a istovremeno se vide i svi skupovi ulaznih i izlaznih promenljivih, kao i stanja sistema zajedno sa skupom uslova.
SDL dijagrami i ASN.1 notacija [4] sa pravilima kodiranja daje pogodnu osnovu za formalizovanje specifikacije programske podr{ke za bilo koji nivo protokola.
Sredi{nje mesto u predlo`enom pristupu automatizaciji direktnog pra}enja ispravnosti programske podr{ke u realnom vremenu imaju SDL dijagrami. Prednost formalne specifikacije ogleda se u tome da se mo`e izvesti simulacija izvr{enja implementirane specifikacije [5]. Ovo mo`e da bude korisno za:
• analiziranje logi~ke korektnosti protokola ili
• kod provo|enja simulacije za odre|ivanje performanse
Analiziranje logi~ke korektnosti protokola se sastoji u ispitivanju usagla{enosti stvarne implementacije sa specifikacijom protokola. Forma SDL dijagrama je vrlo pogodna za proveru svih trasa u algoritmu.
Provo|enje simulacije radi odre|ivanja performanse je naro~ito zna~ajno kod odre|ivanja optimalnih parametara za realne implementacije, kod kojih su prisutni specifi~ni zahtevi u pogledu performanse.
Ovako definisana formalna specifikacija predstavlja osnovu uporednog modela programske podr{ke. Za potrebe ispitivanja njene ispravnosti neophodno je pored formalne specifikacije u uporedni model uklju~iti skup testova po kojima se odigrava ispitivanje svake trase u SDL dijagramima. Testovi se organizuju po grupama i podgrupama ~ime se sistematizuje proces ispitivanja, jer se srodne stavke ispituju u okviru jedne grupe i njenih podgrupa, a {to br`e dovodi do rezultata ispitivanja.
7
1.3. Konfiguracija za ispitivanje
Za potrebe ispitivanja realizovane programske podr{ke, neophodno je obezbediti elemente fizi~ke arhitekture u obliku neke konfiguracije na kojoj }e se odvijati rad te programske podr{ke [6]. Ova konfiguracija treba da zadovolji sve potrebe, kako za programskim resursima u u`em smislu (procesorska jedinica, ulazno/izlazni podsistem, jedinice masovne sme{tajne memorije i sl.), tako i objekte koji su na direktni na~in spregnuti sa ra~unarskim sistemom, a ~ine sastavni deo drugog sistema, onog kojim upravlja ta programska podr{ka. Taj drugi sistem je u slu~aju ra~unarskih mre`a telekomunikacioni podsistem, ~ije se komponente javljaju kao:
• izvori ili odredi{ta poruka iz ra~unara ili
• objekti upravljanja ra~unarskog sistema (krajnji ure|aji, modemi, komutacione matrice i sl.)
U zavisnosti od toga kako se formira konfiguracija za ispitivanje, razlikuju se dve krajnje vrednosti za tip konfiguracije, a samim tim i dva krajnja tipa ispitivanja:
• konfiguracija za ispitivanje u uslovima simulacije
• konfiguracija za ispitivanje u realnom okru`enju
Pored ovih homogenih tipova konfiguracije, odnosno ispitivanja, mogu se pojaviti i hibridna re{enja gde se prepli}u elementi ciljne fizi~ke arhitekture sa simuliranim komponentama. Svaka vrsta konfiguracije, tj. ispitivanja ima svoje prednosti i nedostatke. Koju vrstu u konkretnom slu~aju odabrati zavisi od vi{e faktora. Neki od njih su vezani za kriterijume ekonomi~nosti, a neki za to {ta se `eli ispitati.
Prednosti ispitivanja na simulacionom modelu se zasnivaju na tome da je takvo ispitivanje mogu}e brzo i lako sprovesti, {to je vrlo ekonomi~no. Me|utim, u ovakvom okru`enju su svi spoljni i unutra{nji doga|aji strogo deterministi~ke prirode, te je to i glavni nedostatak ovakvog ispitivanja, jer ta ~injenica onemogu}ava da se dobiju svi uslovi rada koji bi se u realnosti mogli dogoditi.
Na strani ispitivanja u realnom okru`enju su velike prednosti, jer se takvim ispitivanjem dobijaju podaci koji u potpunosti odgovaraju stvarnim uslovima rada. Glavni nedostaci ispitivanja na ciljnoj, realnoj fizi~koj arhitekturi su iz domena ekonomi~nosti, jer ~esto nedostaju mnogi programski i/ili fizi~ki resursi za pribavljanje ili predstavljanje `eljenog parametra koji se ispituje.
8
Poglavlje 2
2. SDL - JEZIK ZA SPECIFIKACIJU I OPISIVANJE
[iroko je prihva}eno da je klju~ za uspe{an razvoj sistema definisanje njegove detaljne specifikacije i opisa. Ovaj zadatak iziskuje odgovaraju}i jezik za opisivanje koji treba da sadr`i slede}e komponente :
• Dobro definisan skup koncepata.
• Nedvosmislene, jasne, precizne i koncizne specifikacije.
• Osnovu verifikacionih specifikacija za proveru potpunosti i ispravnosti.
• Osnovu za odre|ivanje da li implementacija zadovoljava specifikacije.
• Osnovu za odre|ivanje konzistentnosti specifikacije u odnosu jedne na drugu.
• Kori{}enje programskih alata za formiranje, odr`avanje, verifikovanje, simulaciju i proveru specifikacije.
• Programsku podr{ku za generisanje aplikacije bez potrebe za fazom tradicionalnog programiranja.
Gore navedene zahteve ispunjava jezik koji se naziva SDL (engl. Specification and Description Language) i dijagrami koji se nazivaju MSC (engl. Message Sequence Charts).
SDL je standardni jezik za zadavanje i opisivanje sistema. Razvijen je i standardizovan od strane Me|unarodne telekomunikacione unije (engl., International Telecommunication Union - ITU) u preporuci Z.100.
Razvoj SDL je zapo~et 1972. godine nakon perioda istra`ivanja. Prva verzija jezika je izdata 1976. godine, a sledile su nove verzije 1980., 1984., 1988. i 1992. godine. Poslednje tri verzije su zna~ajnije razvile jezik, tako da je danas SDL jedan kompletan jezik u svakom smislu. U ITU postoji predlog za novu i pro{irenu verziju standarda, nazvan SDL-96.
SDL specifikacija jednog sistema je sa~injena od odre|enog broja me|usobno povezanih celina, odn. blokova. Blok mo`e rekurzivno da se podeli na vi{e blokova tako
9
da se oformi hijerarhijska struktura blokova. Kanali defini{u komunikacione puteve preko kojih blokovi komuniciraju jedan sa drugim ili sa okru`enjem. Svaki kanal obi~no poseduje red ~ekanja na bazi "prvi koji je u{ao }e prvi iza}i" (engl., First In First Out ,- FIFO) [7] , a koji sadr`i signale koji se prenose du` kanala. Pona{anje svakog od blokova u hijerarhijskoj strukturi se opisuje komunikacionim procesima. Procesi se defini{u pomo}u automata sa kona~nim brojem stanja.
SDL podr`ava objektno orjentisano projektovanje po tipu koncepta koji omogu}ava specijalizaciju i nasle|ivanje, a koji se mo`e koristiti za sve komponente SDL-a, kao {to su blokovi, procesi, tipovi podataka, itd. O~igledna prednost je mogu}nost projektovanja kompaktnih sistema i vi{ekratno kori{}enje komponenti {to u stvari olak{ava poslove vezane za odr`avanje sistema.
SDL pru`a izbor za dve sintaksno identi~ne forme :
• Grafi~ko predstavljanje (engl. SDL-GR).
• Tekstualno predstavljanje frazama (engl. SDL-PR).
SDL je uglavnom poznat unutar telekomunikacione industrije, ali su tu i {ira podru~ja gde nalazi primenu, naro~ito u polju programske podr{ke za rad u realnom vremenu. Podru~ja primene se mogu sumirati kao :
• Tipovi sistema opisani sa SDL : realno vreme, interaktivni, distrubuirani sistemi.
• Tipovi informacija obezbe|eni pomo}u SDL : pona{anje i struktura.
• Nivo apstrakcije podr`an pomo}u SDL : od nivoa pregleda sistema do funkcionalnih detalja.
2.1. Karakteristike SDL jezika
Osnova teoretskog modela SDL sistema se sastoji od skupa pro{irenih automata sa kona~nim brojem stanja koji rade paralelno [8]. Ovi automati su nezavisni jedan od drugog i komuniciraju preko diskretnih signala.
SDL sistem se sastoji od slede}ih komponenti :
• Struktura
- hijerarhijska dekompozicija sa slede}im glavnim komponentama izgradnje: sistem, blok, proces, i procedura
• Komunikacija
- asinhroni signali sa opcionim signalnim parametrima
- pozivi udaljenih procedura za sinhrono komuniciranje
• Pona{anje
10
- procesi
• Podaci
- apstraktni tipovi podataka koji se mogu nasle|ivati, generalizovati i specijalozovati
- ASN.1 tipovi podataka saglasno ITU preporuci Z.105
• Koncept tipova
- opisivanje hijerarhije tipova sa nasle|ivanjem, generalizacijom i specijalizovanjem
• Modularnost
- komponente kao {to su tipovi blokova ili procesa, zatim tipovi podataka ili signali se mogu grupisati u pakete koji mogu da se uklju~e u sistem, ~ime se omogu}uje odvojeni, tj. modularni razvoj.
Slika 2.1. pokazuje ~etiri glavna hijerarhijska nivoa u SDL : sistem, blok, proces i procedura [9] .
Dodatno, postoji koncept usluga koji se mo`e koristiti unutar procesa. Procedure se mogu koristiti i u procesima i u uslugama.
Sistem mora da sadr`i bar jedan blok, a blok mora da sadr`i bar jedan proces.. Usluge mogu da postoje unutar procesa, izvr{avaju}i se bar jedanput na osnovu primljenih signala. Kori{}enje procedura je na~in za strukturiranje informacija unutar procesa i usluga. Procesi, procedure i usluge se opisuju pogodnom notacijom koja je sli~na simbolima koji se koriste u dijagramima toka algoritma.
Stati~ka struktura sistema je definisana pomo}u blokova.
U SDL nema globalnih podataka. Blokovi komuniciraju pomo}u signala koji se prostiru du` kanala. Ovakav pristup zahteva da se informacija izme|u procesa, ili izme|u procesa i okru`enja mora poslati sa signalima i opcionim signalnim parametrima (slika 2.2.). Signali se {alju asinhrono, {ro zna~i da proces koji je poslao signal nastavlja izvr{avanje svog posla a da ne ~eka potvrdu o prijemu od strane procesa koji prima taj signal.
Sinhrono komuniciranje je mogu}e preko poziva udaljenih procedura. Ove procedure se transformi{u u signal poslat sa dodatnim signalom za potvrdu prijema.
Dinamika pona{anja se u SDL sistemu opisuje u procesu. Proces je automat sa kona~nim brojem stanja, pro{iren podacima. SDL sistem se sastoji od skupa procesa koji su nezavisni jedan od drugog i rade paralelno. Procesi komuniciraju pomo}u diskretnih signala preko signalnih kanala. Hijerarhija sistema sa blokovima je samo stati~ki opis strukture sistema. Procesi se u SDL mogu formirati na po~etku rada sistema, ili mogu biti formirani i okon~ani dinami~ki u vreme izvr{enja (Slika 2.3.). Mogu postojati vi{e od jedne instance procesa. Svaka instanca ima jedinstveni identifikator procesa (PId). Ovim je omogu}eno slanje signala pojedinim instancama procesa. Koncept procesa i instance procesa koji rade autonomno i konkurentno ~ini SDL jezik pogodnim za aplikacije u realnom vremenu.
11
Slika 2.1. Pregled arhitekture SDL sistema
R1C1
[ ... ]
R2 [ ... ]
R3
[ ... ]
BLOK BL1
BL1
BL2
[ ... ]
C2 [ ... ]
C3
[ ... ]
PRIMER SISTEMA
(1,1) PROC 1
(0,5) PROC 2
PROCEDURA PR 1PROCES PROC 2 (0,5)
stanje 1
Pr 1
12
Slika 2.2. Slanje signala izme|u dva procesa
Proces mo`e da ima samo jedan simbol po~etka. Po{to je proces automat stanja, prelazi izme|u dva stanja se de{avaju samo nakon prijema signala. Ukoliko nema ulaznih signala, proces je u neaktivnom stanju. U SDL prelaz ne predstavlja utro{ak vremena. Da bi se vreme moglo modelovati, odnosno da se postave vremenska ograni~enja, postoji koncept vremenskih intervala. Svaki proces ima sopstveni skup vremenskih intervala koji mogu da se podese tako da isteknu u razli~itim trenucima vremena.
Koncept apstraktnih tipova podataka kori{}en unutar SDL je veoma dobro uklopljen u specifikaciju jezika. Apstraktni tip podataka je takav tip podataka koji ne poseduje specifikaciju strukture podataka. Umesto toga, on poseduje specifikaciju skupa vrednosti, skupa operacija dozvoljenih na tipu podatka i skup jednakosti koje operacije moraju da zadovoljavaju. Ovakav pristup ~ini veoma jednostavnim postupak preslikavanja SDL tipova podataka u tipove podataka koje koriste vi{i programski jezici.
SIGNALSig1 (Integer);
(1,1) PROC 1
(1,2) PROC 2
R1 R2[ ... ] [Sig1]
Proces koji {alje signal Spisak signala
Sig 1 (5)
PROC 1 PROC 2
Sig 1(Number)
DCLNumber Integer
Simbol izlaza Simbol ulaza
Deklaracijasignala
13
PROCES PROC 2 (0,5)
stanje 1
Pr 1Zahtev za formiranje(formiranje nove instance procesa tipa Pr1)
Slika 2.3. Formiranje nove instance procesa u vreme izvr{enja
Alternativno, ASN.1 tipovi mogu da se koriste u SDL. To je korisno kada se specificira ili implementira telekomunikaciona aplikacija koja koristi ASN.1. ITU-T preporuka Z.105 defini{e kako se koristi ASN.1 u kombinaciji sa SDL.
Objektno orjentisani koncept SDL pru`a korisniku sna`no oru`je za strukturiranje i ponovnu upotrebu. Koncept je zasnovan na definiciji tipa. Svi strukturni blokovi mogu da se tipiziraju. Definicije tipova se mogu postaviti bilo gde u sistemu, kao i u paketima van sistema.
Jedna od glavnih prednosti kori{}enja objektno orjentisanih jezika je mogu}nost stvaranja novih objekata dodavaju}i nova svojstva postoje}im objektima, ili redefini{u}i svojstva postoje}ih objekata. Ovaj postupak je poznat pod nazivom specijalizacija.
U SDL specijalizaciju tipova je mogu}e izvesti na dva na~ina:
• Podre|enom tipu se mogu dodati svojstva koja nisu definisana u nadre|enom tipu. Npr., mogu se dodati novi prelazi tipu procesa, novi procesi tipu bloka, itd.
• Podre|eni tip mo`e da redefini{e virtuelne tipove i virtuelne prelaze definisane u nadre|enom tipu. Mogu}e je redefinisati kontekst prelaza u tipu procesa, redefinisati kontekst ili strukturu tipa bloka, itd.
14
Poglavlje 3
3. METODOLOGIJA ISPITIVANJA USAGLA[ENOSTI PROGRAMSKE PODR[KE SA PREPORUKAMA
Ispitivanje usagla{enosti obuhvata ispitivanje kako osobina tako i pona{anja implementacije. Ispitivanje usagla{enosti ne obuhvata procenu, niti performanse niti robustnosti ili pouzdanosti implementacije. Ono ne daje ocenu fizi~ke realizacije, niti kako je sistem implementiran, niti kako on pru`a usluge, a ne mo`e, osim na indirektan na~in, dokazati bilo {ta o logi~koj konstrukciji protokola samog po sebi [10].
Svrha ispitivanja usagla{enosti je da pove}a verovatno}u da razli~ite implementacije mogu da me|usobno komuniciraju. Me|utim, treba imati na umu da slo`enost ve}ine protokola ~ini iscrpne testove neprakti~nim i sa tehni~kog i sa ekonomskog stanovi{ta. Tako|e, ispitivanje ne mo`e da garantuje usagla{enost sa specifikacijom po{to ono pre otkriva gre{ke nego njihovu odsutnost. Stoga sama usagla{enost sa testnom konfiguracijom ne mo`e da garantuje povezivanje. Ono {to ispitivanje daje je da implementacija ima zahtevane osobine i da je njeno pona{anje konzistentno potvr|eno u reprezentativnim instancama komuniciranja.
Metodologija se primenjuje na ispitivanje usagla{enosti u vezi sa:
a) specifikacijom protokola;
b) specifikacijom sintakse prenosa koja se koristi u kombinaciji sa specifi~nim protokolom;
c) ispitivanje usagla{enosti sa svim informacionim objektima koji se koriste u kombinaciji sa jednim ili vi{e protokola;
d) specifikacijama kombinacija protokola, koje je mogu}e koristiti u kombinaciji sa specifi~nom sintaksom prenosa i/ili jednim ili vi{e specifi~nih informacionih objekata.
Metodologija je primenjiva na razli~ite faze procesa ispitivanja usagla{enosti. Ove faze karakteri{u slede}e glavne aktivnosti:
15
a) specifikacija apstraktnih testnih konfiguracija za pojedine protokole;
b) realizacija sredstava za testiranje koja mogu da pokre}u izvr{ne oblike apstraktnih testnih konfiguracija;
Za realni sistem se ka`e da pokazuje usagla{enost ako se pokorava zahtevima primenjivih specifikacija u svojoj komunikaciji sa drugim realnim sistemima.
Primenjive specifikacije uklju~uju one koje specificiraju protokole i one koje specificiraju apstraktne sintakse i pravila kodiranja. Zahtevi za usagla{enost:
a) Obavezni zahtevi: Oni se posmatraju u svim slu~ajevima;
b) Uslovni zahtevi: Oni se posmatraju ako se primenjuje skup uslova iz specifikacije;
c) Opcije: One se mogu izabrati da odgovaraju implementaciji, obezbe|uju}i da se posmatraju bilo koji zahtevi primenjivi na opciju.
Nadalje, zahtevi za usagla{enost se mogu postaviti:
a) Pozitivno: Oni defini{u {ta se zahteva da bude obavljeno;
b) Negativno: Oni defini{u {ta se zahteva da ne bude obavljeno;
Kona~no, zahtevi za usagla{enost pripadaju dvema grupama:
a) stati~ki zahtevi za usagla{enost;
b) dinami~ki zahtevi za usagla{enost;
3.1. Ciljevi ispitivanja usagla{enosti
Razlikuju se ~etiri tipa ispitivanja:
a) Osnovna ispitivanja me|usobnih veza - koja pru`aju osnovne dokaze da je ispitivani sistem usagla{en.
b) Ispitivanja mogu}nosti - koja proveravaju da su posmatrane mogu}nosti ispitivanog sistema u saglasnosti sa stati~kim zahtevima usagla{enosti.
c) Ispitivanja pona{anja - koja nastoje da obezbede koliko je mogu}e sveobuhvatno ispitivanje nad punim opsegom dinami~kih zahteva usagla{enosti za relevantne specifikacije unutar mogu}nosti ispitivanog sistema.
d) Ispitivanja usagla{enosti detalja - koja ispituju u dubinu usagla{enost ispitivanog sistema za specifi{ni zahtev, radi dobijanja definitivnog da ili ne odgovora i dijagnosti~ke informacije u odnosu na odre|ene stavke usagla{enosti.
16
Proces procene usagla{enosti obuhvata tri faze:
a) pripremu za ispitivanje;
b) izvo|enje ispitivanja;
c) izradu izve{taja ispitivanja.
Faza pripreme za ispitivanje uklju~uje:
a) izradu dokumenata vezanih za ulazne parametre ispitivanja,
b) izbor apstraknih metoda ispitivanja,
c) pripremu sistema koji se ispituje i sredstava za ispitivanje
Faza izvo|enja ispitivanja obuhvata:
a) pregled stati~ke usagla{enosti, rukovode}i se analizom u odnosu na relevantne stati~ke zahteve usagla{enosti i proveru usagla{enosti;
b) izbor ispitivanja i parametrizaciju zasnovanu na ulaznim parametrima ispitivanja;
c) jednu ili vi{e "kampanja ispitivanja".
Pregled gore opisanog procesa procene usagla{enosti je prikazan na slici 3.1.
Kampanja ispitivanja je proces izvr{avanja skupa parametrizovanih izvr{nih ispitivanja.
Kampanja ispitivanja uklju~uje kori{}enje konfiguracije opreme omogu}uju}i protokolsku razmenu izme|u sistema pod ispitivanjem i ispitnog sistema, s time da ispitni sistem upravlja razmenom. Kampanja ispitivanja uklju~uje slede}a tri tipa ispitivanja:
- osnovna ispitivanja povezanosti;
- ispitivanja mogu}nosti i
- ispitivanja pona{anja.
Ishod ispitivanja je niz doga|aja koji se javljaju za vreme izvr{enja slu~ajeva ispitivanja, uklju~uju sve ulaze i izlaze iz sistema koji se ispituje u ta~kama upravljanja i posmatranja.
Ispitivanje dovodi do zaklju~ka koji mo`e da ima vrednosti ispravan, neispravan i neodre|en:
a) Ispravan - Zna~i da ishod posmatranog ispitivanja daje dokaze o usagla{enosti sa zahtevima za usagla{enost na koje je usredsre|en slu~aj ispitivanja i ispravan je u odnosu na relevantne specifikacije.
b) Neispravan - Zna~i da ishod posmatranog ispitivanja ili pokazuje neusagla{enost sa (najmanje jednim) zahtevom za usagla{enost na koje je usredsre|en slu~aj ispitivanja ili sadr`i bar jedan neta~an doga|aj ispitivanja u odnosu na relevantne specifikacije.
c) Neodre|en - Zna~i da je ishod posmatranog ispitivanja takav da se ne mo`e dati zaklju~ak ni ispravan niti neispravan.
17
Rezultati ispitivanja usagla{enosti }e biti dokumentovani u skupu izve{taja o ispitivanju usagla{enosti. Ovi izve{taji }e biti u dva oblika: sistemski izve{taj o ispitivanju usagla{enosti i protokolski izve{taj o ispitivanju usagla{enosti.
Sistemski izve{taj o ispitivanju usagla{enosti, koji je uvek uklju~en, daje skup stanja usagla{enosti sistema koji se ispituje, uklju~uju}i i skup zaklju~aka dodeljenih za vreme procesa ocene usagla{enosti. Za svaku kori{}enu ispitnu konfiguraciju se izdaje po jedan protokolski izve{taj o ispitivanju usagla{enosti i u njemu se dokumentuju rezultati svih slu~ajeva ispitivanja osiguravaju}i vezu sa dnevnicima usagla{enosti koji sadr`e ishode posmatranih testova. Protokolski izve{taj o ispitivanju usagla{enosti tako|e pru`a vezu na sve neophodne dokumente koji su u vezi sa provo|enjem kampanje ispitivanja za tu ispitnu konfiguraciju.
3.2. Metode ispitivanja
Realni sistemi koji sadr`e implementacije protokola dolaze u {irokom spektru konfiguracija i variraju na~ine prema kojima se njima upravlja i nadzire za vreme ispitivanja [11],[12]. Spektar metoda za ispitivanje se stoga defini{e odgovaraju}e spektru mogu}nosti za upravljanje i nadziranje sistema u ispitivanju. Ovim se prvo karakteri{u osobine sistema u ispitivanju koje se `ele uzeti u razmatranje, zatim se defini{u mogu}i metodi ispitivanja u apstraktnom smislu i kona~no se formiraju uputstva za primenu na realnom sistemu.
Postoji veza izme|u metoda ispitivanja i konfiguracija realnih otvorenih sistema koji se ispituju. Odgovaraju}i metodi ispitivanja se razlikuju saglano :
a) glavnoj funkciji sistema;
b) koji protokoli se koriste;
Kompleti testova imaju hijerarhijsku strukturu (Slika 3.2) u kojoj je va`an nivo test slu~aj. Svaki test slu~aj ima specifi~nu svrhu testiranja, takvu da dokazuje da sistem u ispitivanju ima odre|enu zahtevanu mogu}nost (npr. da je sposoban da podr`i odre|ene veli~ine paketa) ili da poka`e odre|eno zahtevano pona{anje (npr. da se pona{a kako je propisano kada se pojavi odre|eni doga|aj u odre|enom stanju).
Unutar kompleta testova, koriste se ugnje`dene grupe testova za logi~ko ure|enje test slu~ajeva. Grupe testova mogu biti ugnje`dene do proizvoljne dubine. One se koriste radi olak{anja planiranja, razvoja, razumevanja ili izvr{avanja nekog kompleta testova.
Svaka grupa testova mo`e da ima cilj grupe testova. Ako ovakav cilj postoji, sveukupni cilj grupe testova za datu grupu testova se formira spajanjem cilja date test grupe sa onim iz svakog vi{eg nivoa koji sadr`i datu grupu testova.
Modularnost strukture test slu~ajeva se posti`e kori{}enjem koraka testiranja.
18
Iz prakti~nih razloga, srodni koraci testiranja se mogu grupisati u biblioteke koraka testiranja (analogno bibliotekama potprograma ili procedura u programskim jezicima).
Doga|aj testiranja je nedeljiva jedinica specifikacije unutar koraka testiranja (npr. prenos jedne protokolske jedinice podataka). Svi koraci testiranja se specificiraju kao ure|enje doga|aja testiranja ili drugih (manjih) koraka testiranja. Svi koraci testiranja su stoga korespodentni ure|enju doga|aja testiranja.
Slika 3.1. Pregled procesa ocene usagla{enosti
PO^ ETAK
Specifikacijeispitivanja
Priprema testa
KRAJ
Stati~ki zahteviusagla{avanja
Izjave ousagla{enosti
ULAZ
Pregled stati~keusagla{enosti
Izbor iparametrizacija
testa
Kampanja ispitivanja
Testovi osnovnih me| uvezaTestovi mogu}nostiTestovi pona{anja
Analiza rezultata
Izrada izve{taja oispitivanju
Izabranakonfiguracijaza ispitivanje
Parametrizovanaispitna
konfiguracija
Rezultatistati~ke
usagla{enostiRezultatiispitivanja
Izve{taji ousagla{enosti
sistema iprotokola
19
Komplet testova
Grupa testova Grupa testova Grupa testova
Grupa testova Grupa testova
Grupa testova Grupa testova
Test slu~aj Test slu~aj Test slu~aj Test slu~aj Test slu~aj
Korak testa Korak testa Korak testa
Korak testa Korak testa Korak testa
Korak testa Korak testa
Doga| aj testa Doga| aj testa Doga| aj testa Doga| aj testa Doga| aj testa
Slika 3.2. Struktura kompleta testova
20
3.3. Primena metode ispitivanja
Jedan primer gore izlo`ene metodologije predstavlja ispitivanje protokola nivoa 3 dela za prenos poruka [13] u Sistemu signalizacije broj 7, kako je definisano u ITU-T preporuci Q.782 [14]. U ovoj preporuci se nalazi spisak detaljnih ispitivanja ~ime se mo`e potvrditi usagla~enost realizovane programske podr{ke sa zahtevima sadr`anim u preporukama Q.704 [15] i Q.707 [16]. Pojedino detaljno ispitivanje predstavlja primenu jednog test slu~aja. Svi test slu~ajevi su podeljeni u grupe testova saglasno tome na koji se deo protokola odnose. U okviru svakog test slu~aja su navedeni preduslovi koje je neophodno obezbediti da bi se mogli o~ekivati predvi|eni doga|aji testa za svaki njegov korak.
Samo ispitivanje se obavlja na jednoj od unapred definisanih konfiguracija. Najjednostavnija konfiguracija ima oznaku A i predstavlja povezivanje dva komutaciona ure|aja sa dva prenosnika tako da ~ine jedan snop (slika 3.3).
Slika 3.3. Ispitna konfiguracija A
Ova jednostavna konfiguracija je prva iz grupe od ~etiri i koristi se za ispitivanje ispravnosti svih procedura koje se ti~u jednog ili vi{e prenosnika koji pripadaju jednom snopu. Na taj na~in se ispituje
- aktiviranje i deaktiviranje linka;
- procedure prebacivanja na drugi link i vra}anje;
Komutacioni ure| aj
AKomutacioni ure| aj
B
Prenosnik 1
Prenosnik 2
21
- zabrana i prestanak zabrane rada linka;
- neva`e}e poruke.
Da bi se ispitivanje moglo obaviti potrebno je obezbediti protok poruka koje bi nastale kao posledica stvarnih doga|aja u realnim uslovima rada sabra}aja u mre`i. Stoga je razvijen mehanizam razmene poruka koji koristi jedan skup datoteka kao ulazne poruke sa jedne strane, kao i drugi skup datoteka koje sadr`e sve izlazne poruke kao i dodatne informacije o stanjima resursa, automata i gre{kama. Stoga je ispitna konfiguracija A modifikovana i prikazana na slici 3.4.
Slika 3.4. Modifikovana ispitna konfiguracija A
Ulazne poruke se mogu zadavati sa tastature pri startovanju programskog okru`enja ili njihovim direktnim upisom u binarnu datoteku. Takodje je mogu}e slanje odre|ene poruke u odre|eni komutacioni ure|aj komandom sa tastature. Rezultate testiranja ~ini izlazna datoteka u kojoj se bele`e sve poruke pristigle u neki automat sa pripadaju}im podacima.
Na ovaj na~in se za svaki test slu~aj mo`e na~initi izve{taj kojim se opisuju svi doga|aji testa koji odgovaraju pripadaju}im koracima testa. Jedan karakteristi~ni izve{taj je ni`e prikazan za test slu~aj 1.2:
Komutacioni ure| aj
AKomutacioni ure| aj
B
Prenosnik 1
Prenosnik 2
22
TEST 1.2 Naslov : Upravljanje signalnim linkovima Podnaslov : Deaktiviranje skupa linkova Cilj : Postaviti skup linkova izvan rada Uslovi pre testiranja : Jedan signalni link aktiviran Ulazne datoteke: ulaz.a00,ulaz.b00 Izlazne datoteke: izlaz.a00, izlaz.b00 Ta~kama A i B poslata je komanda za deaktiviranje skupa linkova (mDeactivateLinkSet), koja u sebi sadr`i broj skupa linkova i broj linka u okviru skupa linkova koji se `eli deaktivirati. Podrazumeva se da je link prethodno aktiviran. Kao i za aktiviranje zabele`ene su dve izlazne datoteke, za stranu A i B.
23
Poglavlje 4
4. PROGRAMSKA PODR[KA ZA MODIFIKOVANJE IZVORNOG C-KODA I SDL DIJAGRAMA
U procesu ispitivanja usagla{enosti programske podr{ke sa preporukama va`no mesto zauzima priprema programske podr{ke koja je u ispitivanju. Naime, potrebno je modifikovati programsku podr{ku tako da se ostvari sprega izme|u parametara ispitivanja i rezultata ispitivanja. Za potrebe ove modifikacije je razvijen programski alat za modifikovanje izvornog C-koda i SDL dijagrama - CTOSDL [17].
U prilogu 1 (P1) je dat opis kori{}enja ovog programskog alata.
Za konstruisanje SDL dijagrama su kori{}eni slede}i simboli (slika 4.1):
1 stanje
2 prijem poruke
3 slanje poruke
4 obrada
5 definicija funkcije
6 povratak iz funkcije
Slika 4.1 Simboli u SDL
24
Osim is~itavanja, postoji potreba ubacivanja pojedinih test funkcija u SDL dijagram programa. Intervencije na dijagramu je potrebno primeniti na sam izvorni kod programa.
S obzirom na navedene zahteve proiza{li su i osnovni zadaci u realizaciji:
1) Programskim paketom obezbediti dobijanje SDL dijagrama iz programskog koda.
2) Omogu}iti modifikaciju dijagrama, tj. koda.
3) Omogu}iti operativnost doti~nih promena u smislu rada u realnom vremenu.
Jedna od osnovnih namena programskog alata CTOSDL je dobijanje (iscrtavanje) SDL dijagrama funkcija iz bilo kog izvornog koda programa pisanog u C jeziku. Izvorni kod programa je obi~no organizovan po programskim modulima, koji u sebi sadr`e definicije funkcija. Da bi se pristupilo nekoj od funkcija programa, potrebno je u~itati projektnu datoteku i iz nje odabrati programski modul gde se nalazi `eljena funkcija. Kasnije se iz u~itanog modula odabira `eljena funkcija.
Po{to je programski paket CTOSDL prvenstveno namenjen za crtanje dijagrama programa koji rade u realnom vremenu, odnosno programa koji podr`avaju koncepciju stanja i manipulisanja doga|ajima, on omogu}ava modifikovanje inicijalno dobijenog dijagrama. Modifikovanje se mo`e vr{iti u slede}im slu~ajevima:
- kada deo programskog koda nije bitan, odnosno nema potrebe da se nalazi na dijagramu,
- u slu~aju da se jedna, ili skup linija koda mogu tretirati kao jedan SDL simbol sa odre|enim zna~enjem.
^esto se de{ava da se switch-case struktura koristi kao izbor prispelih poruka, ili kao izbor stanja. Navedena razlika se ne mo`e prepoznati neposredno, pa se zato mora omogu}iti naknadno intervenisanje. Inicijalno, svaka switch-case struktura se tretira kao izbor poruka
u nekim slu~ajevima struktura tipa:
if ( uslov )
{
. . .
< obrada >
. . .
}
predstavlja proveru prijema poruke “uslov”. Zbog toga se inicijalni dijagram prikazan na slici 4.2.a. mora modifikovati u dijagram prikazan na Slici 4.2.b.
25
(a) (b)
Slika 4.2. Modifikacija selekcije
Modifikacija SDL dijagrama se mo`e izvr{ti na na dva na~ina:
a) ON-LINE modifikacijom - obavlja se u toku pisanja samog programskog koda. Projektantu programa su na raspolaganju specijalni komentari koje ubacuje u kod. Kasnije, ove komentare koristi program CTOSDL kao smernice za crtanje dijagrama.
b) OFF-LINE modifikacijom - obavlja se na iscrtanom SDL dijagramu, uz pomo} adekvatno realizovanog integrisanog okru`enja programa CTOSDL.
4.1. ON-LINE modifikacija
ON-LINE modifikacija se primenjuje u toku ispisa izvornog koda programa. Projektant-dok pi{e program, istovremeno, mo`e da ubacuje specijalne komentare koji opisuju neke delove dijagrama. Program CTOSDL podr`ava slede}e specijalne komentare:
a) /**/ - specijalni simbol koji ograni~ava deo koda koji se ne iscrtava na dijagramu.
b) /*broj naziv*/
Niz znakova koji }e biti upisani kao naziv simbola.
Tip simbola: jedan od simbola sa slike 4.1, ili neka od dodatih opcija:
26
7 ne iscrtavanje koda u teku}oj liniji
8 switch-case po stanjima
9 if po poruci
Uz pomo} navedenih komentara, mogu}e je izvr{iti mnoge operacije na SDL dijagramu. Osnovne operacije modifikacije dijagrama su:
brisanje jednog ili vi{e simbola dijagrama,
ubacivanje SDL simbola u dijagram,
zamena SDL simbola,
slo`ena modifikacija delova dijagrama.
Da bi se neki delovi dijagrama, odnosno odre|eni niz simbola, obrisali, potrebno je ubaciti specijalne komentare: /**/. Komentari ograni~avaju deo koda koji se ne analizira.
Navedeni postupak je prikazan na slici 4.3. U navedenom slu~aju je potrebno modifikovati dijagram sa slike 4.3.a. (koji bi se kasnije dobio iz koda sa slike 4.3.c.) u dijagram na slici 4.3.b. (odgovaraju}i kod je na slici 4.3.d.). Da bi se to izvr{ilo ubacuju se navedeni komentari na pozicije ispred i iza skupa linija koje ne treba iscrtati. Kao {to se vidi na slici 4.3.d. specijalni komentari su uba~eni ispred i iza ozna~enih linija.
(a) (b)
Slika 4.3. Brisanje dela dijagrama
27
obrada__1_;
obrada__2_;
obrada__3_; Deo koda
obrada__4_; koji treba
obrada__5_; izbaciti
obrada__6_;
obrada__7_;
(c) (d)
Slika 4.3(nastavak). Brisanje dela dijagrama
Ubacivanje simbola u SDL dijagram se obavlja ubacivanjem odgovaraju}eg specijalnog komentara u kod, na mesto gde je on potreban. Dostupni su tipovi specijalnih komentara sa brojevima: 1, 2, 3, 4, 5, 6, 7 i 8.
Postupak ubacivanja je prikazan na slici 4.4. Slika 4.4.a. prikazuje polazni, dok slika 4.4.b. prikazuje modifikovani dijagram. Da bi se ubacio simbol slanja poruke, potrebno je na ozna~eno mesto u kodu (slika 4.4.c.) ubaciti specijalni komentar /*3 poruka*/ . Modifikovani kod je prikazan na slici 4.4.d.
(a) (b)
obrada__1_; Mesto ubacivanja
obrada__2_; novog simbola
(c) (d)
Slika 4.4. Ubacivanje simbola
obrada__1_;
obrada__2_;
/**/
obrada__3_;
obrada__4_;
obrada__5_;
/**/
obrada__6_;
obrada__7_;
obrada__1_;
/*3 poruka*/
obrada__2_;
28
^esto se javlja potreba zamene incijalnog SDL simbola obrade drugim simbolom. U odre|enim slu~ajevima brisanjem i ubacivanjem SDL simbola nije mogu}e izvr{iti smenu. Zato se simbol zamenjuje tako {to se u liniji koda inicijalnog simbola ubaci i specijalni komentar.
Postupak zamene je prikazan na slici 4.5. Slike 4.5.a i 4.5.b. prikazuju dijagrame, dok slike 4.5.c. i 4.5.d. odgovaraju}i kod. U navedenom slu~aju je zamenjen simbol obrade, simbolom prelaska u stanje.
Navedeni postupak omogu}ava tako|e i brisanje samo jednog simbola zamenom za prazan simbol - specijalni komentar /*15 */.
(a) (b)
obrada__1_;
obrada__2_; treba zameniti
obrada__3_;
(c) (d)
Slika 4.5. Zamena simbola
Kao {to je ve} navedeno, postoji potreba da se if selekcija i switch-case struktura tretiraju na razli~ite na~ine. Da bi se to omogu}ilo uvedeni su specijalni komentari /*16 */ i /*18 naziv*/. Navedeni komentari se ubacuju u linije koda gde se nalaze klju~ne re~i if i switch.
Ako je u pitanju if izbor koji treba da se pretvori kao na slici 4.6. onda se izvorni kod sa slike 4.6.a. pretvara u kod sa slike 4.6.b. U ovom slu~aju je uba~en specijalni komentar /*18 uslov*/.
obrada__1_;
obrada__2_; /*5 stanje*/
obrada__3_;
29
if (uslov)
{
obrada;
}
(a) (b)
Slika 4.6. Modifikacija osnovne if selekcije
Za slu~aj modifikovanja dijagrama sa slike 4.7.a. (odgovaraju}i kod je na slici 4.7.c), u dijagram na slici 4.7.b., ubacuje se specijalni komentar /*16 */ u liniju gde se nalazi klju~na re~ switch. Realizovan programski kod je prikazan na slici 4.7.d.
(a) (b)
switch(promenljiva)
{
case VREDNOST1:
obrada;
break;
default:
break;
}
(c) (d)
Slika 4.7. Modifikacija switch-case strukture
if (uslov) /*18 uslov*/
{
obrada;
}
switch(promenljiva) /*16 */
{
case VREDNOST1:
obrada;
break;
default:
break;
}
30
4.2. OFF-LINE modifikacija
OFF-LINE modifikacija je metoda modifikovanja SDL dijagrama uz pomo} realizovanog integrisanog okru`enja programa CTOSDL. Za razliku od ON-LINE modifikacije, ova metoda je mnogo jednostavnija za upotrebu. Korisniku je omogu}eno da intervencije obavlja na ve} nacrtanom SDL dijagramu, bez potrebe editovanja izvornog koda.
U prilogu 1 (P2) je dat opis procedura za obavljanje ovih modifikacija.
4.3. Ubacivanje programskog koda
Jedna od osnovnih namena programa CTOSDL je ubacivanje programskog koda u nacrtan SDL dijagram. Program pru`a mogu}nost da korisnik samo odredi, uz pomo} mi{a, poziciju na dijagramu gde `eli ubaciti kod. Brigu o ure|ivanju i ubacivanju programskog u izvr{ni kod preuzima sam program.
Zbog potrebe ubacivanja ta~no odre|enih programskih funkcija, kao {to su funkcije za testiranje programa, uvedena je programska biblioteka. U programskoj biblioteci je potrebno navesti deklaracije svih funkcija koje }e se odabirati za ubacivanje u izvorni kod programa.
U prilogu 1 (P3) je dat opis procedura za ubacivanje programskog koda.
4.4. Koncepcija programske podr{ke za modifikovanje izvornog C-koda i SDL dijagrama
Pri pisanju programa CTOSDL kori{}ene su slede}e strukture podataka:
a) Sekvencijalne datoteke:
OUT.C - za ~uvanje izvornog koda pri modifikovanju SDL
dijagrama,
BACKFILE.BAK - sadr`i izvorni kod predhodno ura|enog koraka
obrade SDL dijagrama,
DESTIN.DES - me|ukorak pri obradi izvornog koda,
FUNCTION.FUN - datoteka sa nazivima funkcija iz obra|ene
datoteke izvornog koda,
31
LIST.LST, DIRECT.LST, DIR.LST - datoteke koje koristi funkcija
za listanje slogova datoteka.
b) Nizovi slogova:
Niz_simbola - sadr`i SDL dijagram svih funkcija obra|ene
datoteke izvornog koda,
Function - u sastav ovog niza ulaze slogovi koji daju opis funkcija
koje su na|ene u analiziranom programskom modulu.
c) Dvostruko spregnuta lista - koristi se za ~uvanje izmena koje se `ele
izvr{iti na SDL dijagramu.
Obrada izvornog koda se mo`e prikazati dijagramom na slici 4.8. Proces obrade se obavlja u tri prolaza. Globalni zadaci svakog od prolaza su:
• Prvi prolaz - ispravlja izvorni kod, ubacivanjem znakova za kraj reda na odre|enim mestima u kodu. Ubacivanje se vr{i da bi se kasnije SDL dijagram mogao modifikovati na vi{e mesta.
• Drugi prolaz - izbacuje komentare iz izvornog koda, pronalazi podru~ja u kome su definisane funkcije programa, izbacuje delove koda koji su ograni~eni specijalnim komentarima /**/ i formira datoteku DESTIN.DES.
• Tre}i prolaz - semanti~ka analiza koda. Analizira se datoteka DESTIN.DES i formira SDL dijagram u obliku niza Niz_simbola.
Prvi prolaz (p1) se obavlja na samom izvornom kodu (D1) i kao rezultat obrade se dobije modifikovana datoteka (D1’). Pri analizi se `eli posti}i jednozna~nost preslikavanja izvorni kod -> SDL dijagram. Jednozna~nost se ogleda u tome da svaki SDL simbol ima jedinstvenu adresu u izvornom kodu. Za kasniju analizu se koristi broj linije u izvornom kodu kao jedinstvena adresa SDL simbola.
U drugom prolazu (p2) se prolazi kroz izvorni kod (D1’) da bi se prona{li po~eci definisanja svake programske funkcije modula i izbacili suvi{ni delovi koda. Pod suvi{nim delovima koda se podrazumevaju komentari (ne specijalni komentari) i delovi koda ograni~eni specijalnim komentarom /**/. Kao rezultat drugog prolaza se dobija datoteka DESTIN.DES (D2) ~iji su elementi slogovi sastavljeni od sadr`aja i broja linije u izvornom kodu (D1’).
Nakon formiranja datoteke DESTIN.DES, obavlja se semanti~ka analiza koda u tre}em prolazu (p3). U tre}em prolazu se obra|uje datoteka DESTIN.DES, pronalaze klju~ne re~i C jezika i, uz pomo} realizovanih rekurzivnih funkcija, “iscrtava” SDL dijagram svih funkcija u analiziranom programskom modulu. Dijagrama se ne iscrtava na ekranu ve} se dijagram sme{ta u niz (NS). Element navedenog niza je slog koji nosi potpune informacije o polo`aju i zna~enju jednog simbola SDL dijagrama.
D1 D1’ D2 NS
32
p1 p2 p3
p3 p3
DF
NF
Slika 4.34. Obrada datoteke sa izvornim kodom
Da bi se kasnije omogu}io izbor funkcije ~iji }e se SDL dijagram iscrtavati, tre}i prolaz formira i datoteku FUNCTIO.FUN (DF). Ova datoteka predstavlja spisak funkcija prona|enih u analiziranom modulu programa.
Dobijena datoteka (DF) se koristi kao ulazni parametar za funkcije koje iscrtavaju i modifikuju SDL dijagram.
D1 - datoteka izvornog koda,
D1’ - datoteka izvornog koda nakon prvog prolaza,
D2 - datoteka DESTIN.DES,
DF - datoteka FUNCTION.FUN,
NS - niz Niz_simbola[],
NF - niz Function[],
p1 - prvi prolaz,
p2 - drugi prolaz,
p3 - tre}i prolaz.
33
Poglavlje 5
5. OSNOVNI POJMOVI TEORIJE SAOBRA]AJA I JEDNO RE[ENJE REALIZACIJE PRIKUPLJANJA SAOBRA]AJNIH PODATAKA
Odre|ivanje kapaciteta komutacionog ure|aja u mnogome zavisi od pretpostavljenih parametara i matemati~kog modela koji se koriste za njegovo projektovanje. Radi toga je neophodno na komutacionim ure|ajima prikupljati relevantne parametre i verifikovati primenjene matemati~ke modele.
Pre pristupa opisu realizacije prikupljanja saobra}ajnih podataka ukratko }e se navesti osnovni parametri i naj~e{}e kori{}eni matemati~ki modeli.
5.1. Osnovni pojmovi teorije saobra}aja
Poziv je osnovna fizikalna veli~ina u teoriji telekomunikacijskog saobra}aja i predstavlja inicijativu nekog izvora da bi se zapo~elo uspostavljanje veze do `eljenog odredi{ta s kojim se `eli razmeniti ili mu predati neke informacije [19],[20].
Za poziv se ka`e da je uspe{an ako inicijator uspeva da preda ili razmeni informaciju sa `eljenim odredi{tem, dok svaki drugi rezultat pozivanja predtavlja neuspe{an poziv.
Ovakva definicija poziva te njegove uspe{nosti i neuspe{nosti vredi samo onda ako su za ~itavo vreme trajanja poziva inicijator i odredi{te u trajnoj vezi, a informacija se ne obra|uje radi trajnijeg uskladi{tenja i naknadne predaje.
34
Dakle, razmatra se sistem s gubicima. Izvori poziva kao uzro~nici telekomunikacijskog saobra}aja imaju slede}e osnovne karakteristike, koje su bitne za njihovu matemati~ku interpretaciju:
1. Svaki izvor generi{e poziv potpuno slu~ajno, tj. nezavisno jedan od drugog i od stanja organa za poslu`ivanje.
2. Izvor poziva koji je generisao jedan poziv ne mo`e generisati novi dokle god je taj poziv na poslu`ivanju, tj. samo slobodan izvor mo`e biti potencijalni generator poziva.
3. Ako se poziv pojavi kada su svi organi za poslu`ivanje zaposednuti, onda se smatra da se poziv izgubi i uzima se da je trajanje takvog izgubljenog poziva ravno nuli, pa je izvor odmah slobodan za generisanje slede}eg.
Ukoliko svaki izvor saobra}aja mo`e dose}i bilo koji organ za poslu`ivanje, ukoliko je on slobodan, ka`e se da postoji potpuna dostupnost od izvora saobra}aja do organa za poslu`ivanje.
Ukoliko to nije slu~aj, nego izvor saobra}aja mo`e dose}i samo k organa za poslu`ivanje od ukupno n, a da je pri tom n > k, postoji nepotpuna dostupnost od izvora saobra}aja do grupe organa za poslu`ivanje.
Ako se zamisli da se poslu`ivanje nekog poziva obavlja u vi{e faza, onda za odre|ivanje raspodele vremena poslu`ivanja mo`e da se koristi Erlangova funkcija gustine raspodele:
b t f ff t
fe
ff t( , )
( )
( )!= ⋅ ⋅ ⋅ ⋅
−⋅
−− ⋅ ⋅µ µ µ
1
1
Gde je:
µ - intenzitet prestajanja poziva, tj. recipro~na
vrednost srednjeg vremena poziva
f - broj faza.
t - vreme trajanja poslu`ivanja.
Familija Erlangovih funkcija gustine veoma dobro slu`i za matemati~ko opisivanje izmerenih vremena trajanja poslu`ivanja, jer odabiraju}i razne vrednosti za f mo`e se naj~e{}e sasvim zadovoljavaju}e pribli`iti eksperimentalno dobivenoj funkciji.
U principu se razlikuju dve vrste saobra}aja i to: ponu|eni (traffic offered) i obavljeni (traffic carried). Od obe vrste saobra}aja merljiv je samo obavljeni saobra}aj.
Ponu|eni saobra}aj je jednak srednjem broju nastalih poziva tokom srednjeg vremena poslu`ivanja. Njegov matemati~ki model ima slede}i izgled:
[ ]ponA t t u B u dut
( ) ( ) ( )= − ⋅ − ⋅∫ λ 10
35
Gde je:
λ(τ) - intenzitet nastajanja poziva u svakom momentu τ.
B(u) - funkcija raspodele vremena trajanja poziva. Ova funkcija ima slede}i oblik:
B(u) = 1 - e µ u u - vremenski interval manji od t.
Za stacionarni slu~aj se mo`e pisati:
Ak t
Tpon = ⋅
Gde je:
k - broj poziva.
t - srednje vreme trajanja jednog poziva.
T - vremenski period posmatranja.
Obavljeni saobra}aj je srednji broj zaposednutih organa za poslu`ivanje u odre|enom trenutku. Njegov matemati~ki model ima sli~an oblik modelu ponu|enog saobra}aja:
[ ]A t t u F u duob
t
( ) ( ) ( )= − ⋅ − ⋅∫ λ 0
0
1
Gde je:
λo(t) - intenzitet nastajanja poziva preuzetih na poslu`ivanje.
F(u) - funkcija raspodele vremena trajanja poslu`ivanja poziva.
t - vremenski trenutak u kome se posmatra vrednost obavljenog saobra}aja.
Intenzitet saobra}aja je ~esto kori{}ena jedinica telekomunikacijskog saobra}aja, i jednak je koli~ini saobra}aja u jedinici vremena. Nema fizi~ku dimenziju, a jedinica ja nazvana Erlang [ E ] . Jedinica je dobila naziv po danskom matemati~aru A. K. Erlangu.
Intenzitet saobra}aja se iz prakti~kih razloga uzima kao koli~ina saobra}aja u jednom satu, tako da }e grupa organa za poslu`ivanje obaviti saobra}aj od 1 E ako je srednji broj zaposednutih organa u tom jednom satu bio jedan. Drugi zaklju~ak koji se mo`e izvesti iz gornje definicije je da jedan organ mo`e da obavi maksimalno saobra}aj intenziteta 1 E.
Iz razloga jednostavnosti, posmatra}e se grupa organa povezanih u potpuni snop. Dolazak telefonskih poziva se mo`e predstaviti Puasonovim tokom doga|aja [21].
Osnovne karakteristike ovog toka koji je u stvari slu~ajni proces, su:
a) Stacionarnost
36
b) Ordiniranost
c) Besposledi~nost
Stacionarnost je osobina procesa da njegove karakteristike ne zavise od trenutaka zapo~injanja psmatranja ili, preciznije, da broj doga|aja u delu vremena od T do T+t ne zavisi od T ve} samo od t. Ordinarnost je svojstvo procesa da se u kratkom delu vremena ne doga|a vi{e doga|aja, tj. da je verovatno}a doga|anja vi{e od jednog doga|aja zanemarljiva.
Besposledi~nost je svojstvo procesa da broj doga|aja u delu vremena od T do T+t ne zavisi od broja doga|aja pre trenutka ozna~enog sa T.
Na osnovu ovih svojstava pokazuje se da za Puasonov tok va`i slede}e:
1.Vreme izme|u dva sukcesivna doga|aja je slu~ajna veli~ina za koju va`i negativno-eksponencijalna raspodela verovatno}e du`ine trajanja tj:
P t x e x( )< = − − ⋅1 λ
Gde je:
λ - srednji broj doga|aja ,tj. poziva u jedinici vremena.
2. Verovatno}a da se desi k doga|aja u vremenu od T do T+t je:
P tt
kek
kt( )
( )
!= ⋅ ⋅ − ⋅λ λ
Proces koji je obele`en pomenutim svojstvima zove se jo{ i proces ra|anja, jer se broj doga|aja, tj. poziva pove}ava.
U komutacionom ure|aju se obra|uju (poslu`uju) pozivi. Osnovno svojstvo ovog poslu`ivanja je da je du`ina poziva slu~ajna veli~ina sa negativno-eksponencijalnom raspodelom verovatno}a du`ine trajanja, tj.:
G t x ex
tm( )< = −−
1
Gde je:
tm - srednje vreme trajanje poziva.
U telekomunikacijskom sistemu proces poslu`ivanja poziva predstavlja proces ra|anja i umiranja.
Vremenski period u kojem su svi organi za poslu`ivanje zaposednuti naziva se kriti~nim vremenom. Bilo koji poziv unutar kriti~nog vremena uzrokuje gomilanje poziva. Gomilanja su prema tome gubici u sistemu.
Gomilanje po vremenu je odnos izme|u ukupnog vremena zaposednutosti svih organa za poslu`ivanje prema ukupnom vremenu posmatranja.
37
Navedeno je da je i raspodela du`ine vremenskih intervala izme|u nastanka pojedinih poziva i raspodela du`ine trajanja poziva mo`e sa zadovoljavaju}om ta~no{}u aproksimirati negativno eksponencijalnom raspodelom, kao i da je proces pojave poziva stacionaran, ordinaran i besposledi~an.
Na osnovu ovih pretpostavki i na osnovu Erlangove funkcije gustine raspodele izveden je slede}i izraz za gomilanje u sistemima s gubicima:
E A
A
nA
i
n
n
i
i
n( ) !
!
=
=∑
0
Gde je:
n - broj organa za poslu`ivanje.
A - intenzitet ponu|enog saobra}aja.
U komutacionim ure|ajima postoje delovi koji se sa stanovi{ta teorije saobra}aja pona{aju kao sistemi sa ~ekanjem (npr., primopredajnici tonskih frekvencija i upravlja~ki blok). Pona{anje grupe primopredajnika se mo`e opisati postoje}im matemati~kim modelima za sisteme sa ~ekanjem. Me|utim na na~in rada upravlja~kog bloka ne mogu se primeniti pomenuti matemati~ki modeli. Ovi modeli su razvijeni uz pretpostavku poslu`ivanja istovremeno samo jednog poziva, dok procesor gledano u du`em vremenskom periodu poslu`uje vi{e poziva istovremeno, jer su oni razlo`eni na vi{e faza obrade.
Ako se posmatra jednostavan slu~aj sistema sa ~ekanjem, izvedeni su izrazi za verovatno}u da }e do}i do ~ekanja i verovatno}u da je ~ekanje du`e od nekog odre|enog vremena. Iz pretpostavku Erlangove raspodele dobije se izraz za verovatno}u da }e do}i do ~ekanja uz ponu|eni saobra|aj A i broj organa za poslu`ivanje n:
(An/n!) * (n/(n-A))
E2,n(A) = ___________________________
n-1
Σ(A i/i!) + (An/n!) * (n/(n-A))
i-= 0
Verovatno}a da }e ~ekanje biti t uz gornju pretpostavku bi}e:
W(t) = E2,n(A) e-µµµµ (n-A) t
gde je µµµµ recipro~na vrednost srednjeg trajanja poziva.
38
Izvod ovih izraza se zasniva na istim principima kao i izvod izraza sa gubicima, samo {to se mora uzeti u obzir da broj poziva u sistemu mo`e biti ve}i od broja organa za poslu`ivanje. Razliku izme|u te dve veli~ine predstavljaju pozive na ~ekanju.
Napred navedeni matemati~ki model bi se mogao primeniti samo na jednu fazu rada upravlja~kog bloka. Me|utim, prilikom poslu`ivanja prepli}e se poslu`ivanje raznih faza raznih poziva, {to bi uzrokovalo veoma slo`en matemati~ki aparat za opisivanje takvog na~ina rada.
Radi toga se kvantitativni podaci o optere}enju upravlja~kog bloka dobijaju metodom simulacije koja se potvr|uje u eksploataciji.
U narednom poglavlju }e se opisati metoda za dobijanje te kvantitativne mere.
5.1.1.Sistemi signalizacije
Jedna od osnovnih aktivnosti komutacionog sistema pri poslu`ivanju poziva je njegova interakcija sa okolinom [22]. Pri tome se pod okolinom komutacionog sistema podrazumevaju svi korisni~ki i spojni vodovi priklju~eni na sistem. Razmena posredstvom signala je signaliziranje, a skup signala je sistem signalizacija.
Signali se dele na ~etiri kategorije :
1. Signali kojima se zahteva veza, odnosno njeno osloba|anje,
2. Signali koji nose podatke o adresama,
3. Signali koji daju obave{tenje o stanju veze, odnosno etapi poslu`ivanja,
4. Signali koji su rezultat nadgledanja posmatrane veze.
Skup vi{e signala razli~itih kategorija omogu}uje kompletan ciklus poslu`ivanja poziva u komutacionom sistemu, i takav skup se obi~no naziva sistemom signalizacije.
Proces signalizacije se u komutacionim ure|ajima obavlja tako da se za to koriste odre|eni resursi, tj. ovaj proces optere}uje kako upravlja~ke organe, tako i spojne vodove. Stoga je neophodno razmotriti uticaj primenjene signalizacije na saobra}ajne karakteristike komutacionih ure|aja.
Tehnike signalizacije predstavljaju na~ine i sredstva realizacije signala u okviru pojedinih sistema signalizacije. Vrste tehnike signalizacije :
1) Tehnika prekidanja signalne petlje je najstarija i jo{ uvek primenjivana tehnika signalizacije komutacionih sistema sa terminalima. Princip dobijanja signala ovom tehnikom se zasniva na prekidanju i uspostavljanju toka jednosmerne struje u kolu koje ~ini takozvanu signalnu petlju. Rad svih telefonskih aparata sa broj~anikom i teleprintera se zasniva na kori{}enju ove tehnike.
39
2) Vi{efrekvencijska tehnika se bazira na kodovanju signala ( svakom signalu iz skupa odgovara kombinacija unapred odre|enog broja elementarnih signala u ovom slu~aju frekvencija ). Svaki signal se formira odre|enom kombinacijom iz ovog skupa.
3) Tehnika komunikacije porukama kod koje se komunikacija realizuje putem poruka sa slede}im tipi~nim formatom poruke :
F I C AN AO
Gde je:
F - polje provere ispravnosti poruke,
I - korisni~ki i signalni podaci,
C - upravlja~ki podaci,
AN - adresa odredi{ta,
AO - adresa izvora( address of origin ).
Podela se sprovodi na osnovu polo`aja kola kojim se prenose signali u odnosu na kolo korisni~kih poruka :
1) Signalizacija po pridru`enom kanalu (engl., Channel Associated Signalling - CAS) - signali se prenose po kolu odnosno kanalu po kome se prenose odgovaraju}e korisni~ke poruke ili po posebnom signalizacionom kolu/kanalu stalno pridru`enom kolu/kanalu korisni~ke poruke. (Primena: analogne i analogno/digitalne telekomunikacione mre`e).
2) Signalizacija po zajedni~kom kanalu (engl., common channel signalling - CCS) - signali koji odgovaraju ve}em broju kola/kanala korisni~kih poruka {alju se u formi poruka po posebnom zajedni~kom kolu/kanalu. (ISDN, ATM.).
Osnovne osobine ovog sistema signalizacije pod 2) su tehnika komunikacije porukama i prenos signala po zajedni~kom kanalu, CCS.
Glavne karakteristike :
- standardizacija na internacionalnom planu (uz mogu}e nacionalne varijacije),
- pogodnost za primenu u nacionalnim i internacionalnim (interkontinentalnim) mre`ama,
- primenljivost na razli~ite telekomunikacione slu`be, kao {to su telefonija, slu`be na bazi prenosa podataka, teksta i dr.
40
- mogu}nost {irokog repertoara signala,
- visoka pouzdanost prenosa poruka,
- struktura podataka prilago|ena radu procesora (signalne poruke su umno{ci 8 bita),
- ne postoji nikakvo uslovljavanje vremena preno{enja signala, jer se signalizacija obavlja po posebnom kolu u odnosu na kola korisni~kih poruka, tj. du`ina signalizacije nije atribut koji slu`i za raspoznavanje,
- koristi razli~ite medijume prenosa : kabl ( bakarni, opti~ki ) i slobodan prostor.
- velika brzina prenosa signala : koristi uglavnom protok od 64kb/s, tipi~an za digitalne telekomunikacione mre`e,
- po potrebi se primenjuju i ni`i protoci u slu~aju na primer analognih signalizacionih kola (kod DSS1, gde se po parici ima brzina od 16 kb/s),
- ima mogu}nost automatskog nadgledanja i upravljanja signalizacionom mre`om itd.
Po{to se posmatrani sistem signalizacije realizuje tehnikom komunikacije porukama, postoji protokol, odnosno skup pravila po kojima se obavlja ova komunikacija izme|u odre|enih entiteta telekomunikacione mre`e.
Funkcije signalizacije su raspore|ene na nivoe i ovi su funkcionalno nezavisni :
1. Signalni vod,
2. Funkcije signalnog voda,
3. Funkcije signalne mre`e,
4. Korisni~ki delovi.
Funkcije 1,2 i 3 ~ine deo za prenos poruka.
Defini{u procedure za ispravnu razmenu poruka po signalnom vodu. Poruke kojima se prenose signalne informacije pakuju se u odre|ene formate. Postoje tri osnovne poruke :
a) signalna poruka, koja slu`i za preno{enje signalne informacije dobijene sa vi{eg signalnog nivoa,
b) poruka stanja voda, koja sadr`i informacije o signalnom vodu i koristi se za inicijalizaciju signalizacije i upravljanje tokom poruka,
c) poruka za popunu, ne sadr`i informacije, a {alje se kad je potrebno odr`ati ciklus signalizacije za vreme dok nema signalnih poruka.
41
5.2.Programska podr{ka za merenje saobra}aja i prikupljanje statisti~kih podataka
Osnovni zadatak se sastojao u izradi ra~unarskih programa koji su trebali da re{e:
1) Merenje saobra}aja na perifernim organima,
2) Merenje saobra}aja po signalnom kanalu,
3) Prikupljanje statisti~kih podataka
Programsko re{enje je uslovljeno arhitekturom upravlja~kog bloka komutacionog ure|aja [23], i procesorima (sa njihovim pripadaju}im resursima fizi~ke arhitekture i programske podr{ke) [24] :
RP - regionalni procesori (upravljanje perifernom opremom),
CP - centralni procesor ( obrada poziva ),
OR - operaterski ra~unar ( nadzor i operativno vo|enje ),
TER - terminal,
Telekomunikacioni deo komutacionog ure|aja se sastoji iz slede}ih glavnih komponenti [25] :
GS - grupni stepen (komutacija),
KS - korisni~ki stepen,
ET - linijski prilagodni organ,
DTMF - blok za ton-frekventno biranje,
Arhitektura komutacionog ure|aja je data na slici 5.1.
42
Slika 5.1 Arhitektura komutacionog ure|aja
KS
KS
KS
KS
DTMF
DTMF
DTMF
DTMF
ET
ET
GS
RP RP RP RP
CP
OR
TER TER
43
5.2.1.Merenje saobra}aja na perifernim organima
Tok doga|aja prilikom merenja saobra}aja je slede}i [26], [27]:
Operater na terminalu zadaje osnovne parametre za iniciranje merenja saobra}aja, koje prima sofver na terminalu (TER), formira poruku FORMIRAJ_MER i {alje operaterskom ra~unaru (OR). U zavisnosti od raspolo`ivih resursa OR vra}a poruku FORMIRAJ_POT ka TER-u (mogu}e je sprovesti merenje saobra}aja) ili poruku odbijanja zahteva FORMIRAJ_ODB. OR upore|uje zadato vreme po~etka merenja saobra}aja sa trenutnim vremenom i u trenutku poklapanja {alje poruku ZAHTEV_MER ka CP-u. Ukoliko postoje slobodni resursi CP vra}a ka OR-u poruku ZAHTEV_POT, odnosno u slu~aju nedostatka resursa poruku ZAHTEV_ODB. Ukoliko je zahtev potvr|en, u svakom zadatom intervalu merenja CP {alje poruku rezultata ka OR-u koji te poruke skladi{ti u datoteku rezultata. Ti rezultati pristi`u sa CP-a sve dok se na OR-u ne otkrije istek intervala trajanja merenja. Tada se generi{e poruka KRAJ_MER od TER-a ka CP-u kojom se on izve{tava da oslobodi resurse za odre|eno merenje i da prestane sa slanjem rezultata.
Pregled merenja koja su trenutno u toku kao i merenja koja su zavr{ena, se na zahtev operatera dobijaju razmenom poruka ZAHTEV_ZAGL (TER->OR) i poruke kojom se prenosi sadr`aj samog zaglavlja merenja sa svim informacijama o odre|enom merenju IZVESTAJ_ZAGL (OR->TER).
Ukoliko operater prilikom zadavanja ulaznih parametara primi informaciju da nema resursa tada na OR-u mora obrisati neka merenja a samim tim i resurse koje je to merenje zauzimalo (memorija,datoteke...). To se radi kombinacijom poruka BRISANJE_MER (TER->OR) i potvrdom BRISANJE_POT (OR->TER).
Pregled rezultata odre|enog merenja se na zahtev korisnika obavlja slanjem poruke ZAHTEV_REZ (TER->OR) i nizom poruka IZVESTAJ_REZ (OR->TER) pomo}u kojih se obavlja prenos datoteke rezultata sa OR-a na TER (svaka poruka IZVESTAJ_REZ se potvr|uje jednom porukom IZVESTAJ_REZ_POT : princip handshaking-a )).
44
Graf razmene me|uprocesorskih poruka:
FORMIRAJ_MER
FORMIRAJ_POT
FORMIRAJ_ODB
ZAHTEV_MER
OR CPTER
ZAHTEV_POT
ZAHTEV_ODB
MERENJE_REZ
KRAJ_MER
ZAHTEV_ZAGL
IZVESTAJ_ZAGL
BRISANJE_MER
BRISANJE_POT
ZAHTEV_REZ
IZVESTAJ_REZ
IZVESTAJ_REZ_POT
Polje signalne informacije za poruke iz skupa za ONIOV (Odr`avanje nadzor i operativno vo|enje: SIO=0xAA) je slede}eg izgleda:
H1 H0 SLC OB OP DB DP
4 4 4 6 8 6 8 bita
Gde je:
H1 i H0 - kodovi zaglavlja poruka
SLC - kod signalnog linka, tj. kod procesora koji upravlja tim linkom (engl., Signal Link Code )
45
OB - kod funkcijskog bloka u podsistemu za ONIOV izvornog procesora (engl., originating block )
OP - kod izvornog procesora (engl., originating processor )
DB - kod funkcijskog bloka u podsistemu za ONIOV odredi{nog procesora (engl., destination block )
DP - kod odredi{nog procesora (engl., destination processor )
U slede}oj tabeli su prikazani kodovi zaglavlja poruka:
Naziv poruke H1 H0 Smer poruke
FORMIRAJ_MER 0001 0000 TER->OR
FORMIRAJ_POT 0010 0000 OR->TER
FORMIRAJ_ODB 0011 0000 OR->TER
ZAHTEV_MER 0100 0000 OR->CP
ZAHTEV_POT 0101 0000 CP->OR
ZAHTEV_ODB 0110 0000 CP->OR
MERENJE_REZ 0111 0000 CP->OR
KRAJ_MER 1000 0000 OR->CP
ZAHTEV_ZAGL 1001 0000 TER->OR
IZVESTAJ_ZAGL 1010 0000 OR->TER
ZAHTEV_REZ 1011 0000 TER->OR
IZVESTAJ_REZ 1100 0000 OR->TER
IZVESTAJ_REZ_POT 1101 0000 TER->OR
BRISANJE_MER 1110 0000 TER->OR
BRISANJE_POT 1111 0000 OR->TER
Formati poruka za merenje saobra}aja su dati u prilogu 2 (P2.1).
46
5.2.2.Merenje signalnog saobra}aja
Signalni kanal ( 16-ti kanal ) obavlja funkciju prenosa kontrolnih informacija za uspostavljanje i raskidanje veze ili signalizacije za neke specijalne usluge.
Svaki kanal je u stvari kolo od dva kanala za jedan i za drugi smer tako da se informacija mo`e prenositi istovremeno i u jednom i u drugom smeru. To zna~i da se u okviru jednog signalnog kanala moraju posmatrati dva smera:
a) DOLAZ i
b) ODLAZ,
tako da je za odre|ivanje vrednosti intenziteta obavljenog saobra}aja potrebno posedovati informacije o broju bita koji su poslati signalnim kanalom, tj. o broju bajtova za oba smera. Na primer ukoliko se u dolazu ostvari prenos od 50kbita u jednoj sekundi a u odlazu 30kbita u istom vremenskom intervalu, tada }e vrednost za intenzitet obavljenog saobra}aja iznositi:
Aob = (30 + 50) / ( 64 + 64 ) [ E ] = 0,625 [ E ]
u slu~aju brzine 16. kanala od 64 kb/s.
To zna~i da je potrebno imati informacije o broju bajtova u odlazu kao i o broju bajtova u dolazu po signalnom kanalu. Ti podaci se mogu dobiti od nivoa 3. Me|utim, to bi bilo dovoljno samo u slu~aju idealne veze, kada se primljena ( poslata ) poruka uvek prima korektno, tj. ne dolazi do gre{ke u prenosu. Ukoliko do|e do gre{ke u prenosu ponovo se {alju te iste poruke. Nivo 2 (u odlazu) prima poruku od nivoa 3 koja sadr`i SIF + SIO + LIO, i na nju dodaje kontrolne informacije BSN, BIB, FSN, FIB i CK, tj. ukupno 32 bita ( 4 bajta ). Analogno u dolazu, nivo 2 te informacije 'skida' sa poruke i tako ih prosle|uje nivou 3, {to zna~i da se za svaku poslatu (primljenu) poruku mora dodati jo{ ~etiri bajta da bi rezultat odgovarao stvarnom broju bajtova koji prolaze signalnim kanalom. Problem je i u tome {to retransmisiju poruke sprovodi nivo 2 a da informaciju o tome ne poseduje nivo 3 od kojeg se dobijaju podaci o braju bajtova. Broj retransmitovanih poruka ipak nije dovoljna informacija jer se ne zna du`ina retransmitovanih poruka. Precizan podatak je broj retransmitovanih bajtova po signalnom kanalu.
Na osnovu ovog razmatranja skup podataka koji omogu}ava prora~un intenziteta obavljenog saobra}aja je :
a) u odlazu
1. ukupan broj poslatih bajtova ( Bo ),
2. ukupan broj poslatih poruka ( Po ),
47
3. ukupan broj retransmitovanih bajtova ( Ro ),
b) u dolazu
1. ukupan broj primljenih bajtova ( Bd ),
2. ukupan broj primljenih poruka ( Pd ),
3. ukupan broj retransmitovanih bajtova ( Rd ),
Koriste}i ove podatke dobija se da je ukupan broj bajtova u odlazu :
No = Bo + Po x 4 + Ro
i ukupan broj bajtova u dolazu :
Nd = Bd + Pd x 4 + Rd
Ukoliko se sve ovo posmatra u vremenskom intervalu od T sekundi tada je izraz za intenzitet obavljenog saobra}aja ( 16000 bajtova = 128 kbita ):
Aob = ( No + Nd ) / (16000 x T ) [ E ]
Formati poruka za merenje signalnog saobra}aja su dati u prilogu 2 (P2.2).
6.2.3.Prikupljanje statisti~kih podataka
Tri glavne karakteristike svake poruke u sistemu signalizacije br. 7 su od interesa prilikom prikupljanja statisti~kih podataka :
1. Izvor poruke,
2. Odredi{te poruke,
3. Tip poruke.
Najelementarniji slu~aj je pra}enje broja poruka jednog tipa X u odre|enom vremenskom intervalu od izvora Y do odredi{ta Z, dok je najop{tiji slu~aj pra}enje skupa poruka na relaciji izme|u skupa izvora i skupa odredi{ta gde se mo`e posmatrati svaka kombinacija poruka tipa i od izvora j ka odredi{tu k.
Formati poruka za prikupljanje statistike su dati u prilogu 2 (P2.3).
48
Poglavlje 6
6. PERFORMANSA KOMUTACIONOG URE\AJA
Ispravnosti rada programske podr{ke komutacionih ure|aja je funkcija, izme|u ostalog i optere}enja prcesora na kome se taj posao obavlja. Ta zavisnost se naro~ito ogleda u ~injenici da se formalno ispravna, usagla{ena i proverena programska podr{ka mo`e pokazati neadekvatnom kada se procesor na|e u uslovima preoptere}enja.
Preoptere}enje je takva saobra}ajna ponuda koju organi komutacionog urte|aja ne mogu da zadovolje sa propisanim stepenom usluge. Glavna uska grla koja imaju najve}i udeo u preoptere}enju su komponente upravlja~kog dela komutacionog ure|aja [28], [29].
Osnovna razlika izme|u preoptere}enja govornih delova komutacionog ure|aja i upravlja~kog je u tome {to je njegov uticaj na govorne delove znatno manji od uticaja na upravlja~ki deo. Govorni delovi komutacionog ure|aja uvek obavljaju korisni saobra}aj bez obzira na preoptere}enje. Bez obzira na veli~inu preoptere}enja jedan deo korisnika uvek na vreme dobija zadovoljavaju}u uslugu. Na vodovima i u komutacionom polju ima preoptere}enja ali zbog toga nema jalovog saobra}aja.
Kod upravlja~kog organa (posmatranog bez za{tite od preoptere}enja, ZOP) de{avaju se suprotne stvari. Upravlja~ki organ predstavlja sistem sa ~ekanjem u fazama. Pri pojavi preoptere}enja korisnici ~ekaju sve du`e i du`e ne znaju}i u kojoj su fazi obrade. Oni sve ~e{}e odustaju bez dobijene usluge ostavljaju}i sav posao procesora koji je ura|en za njih kao jalovi saobra}aj. Svojim ponovnim pozivom oni stvaraju dodatno preoptere}enje koje izaziva du`e ~ekanje itd. Upravlja~ki organ i korisni~ka ponuda ulaze u lavinski proces ~ije je osnovno svojstvo sve ve}i deo jalovo obavljenog procesorskog posla. Na svom vrhuncu proces izgleda ovako: procesor je neprekidno zauzet, vreme ~ekanja na njegovu uslugu je predugo za korisnike koji smatraju da rad komutacionog ure|aja nije ispravan i listom odustaju, ponu|eni saobra}aj se uve}ava preko svake mere jer ga ~ini i normalna i ponuda velikog broja ponovljenih poziva a obavljeni saobra}aj pada ispod tolerantnih granica.
Mere ZOP su takvi postupci odabira novih poziva i njihove obrade koji pove}avaju deo uspe{no ostvarenih veza.
49
U procesu merenja parametara preoptere}enja se koriste slede}i termini:
- optere}enje: Ukupni broj poku{aja poziva prisutnih u komutacionom ure|aju za vreme datog intervala vremena (tj. ponu|eno optere}enje)
- preoptere}enje: Onaj deo ukupnog ponu|enog optere}enja u komutacionom ure|aju koji prevazilazi projektovani kapacitet obrade komutacionog ure|aja. Preoptere}enje se obi~no iskazuje kao procenat projektovanog kapaciteta.
- propusnost: Broj poku{aja poziva koji su uspe{no obra|eni u jedinici vremena.
- projektovani kapacitet: Srednja vrednost ponu|enog optere}enja pri kojoj komutacioni ure|aj ispunjava sve zahteve za usluge.
6.1. Performansa obrade poziva za vreme preoptere}enja
Komutacioni ure|aj mora da nastavi obradu specificiranog optere}enja ~ak i onda kada ponu|eni poku{aji poziva prevazilaze njen raspolo`ivi kapacitet obrade poziva.
Pod centralnim procesorom se podrazumeva onaj procesor u komutacionom ure|aju bez ~ijeg u~e{}a ni jedna veza ne mo`e da se ostvari. Ovakvih procesora mo`e da bude i vi{e ali }e se zbog jednostavnosti posmatrati komutacioni ure|aj sa samo jednim centralnim procesorom. Svi ostali procesori u komutaciji ~iji je rad bilo ~ime ograni~en na deo korisnika su van razmatranja.
Centralni procesor obradu jednog poziva obavi u nekoliko navrata. To je posledica postupnosti procesa uspostavljanja i raskidanja veze u kojoj se razlikuju faze slobodnog biranja, biranja, uspostavljanja veze i raskidanja. Svaki od ovih poslova mo`e biti ura|en u nekoliko faza (od nekoliko do nekoliko stotina). Prilikom poku{aja prora~una kapaciteta ovog procesora postavlja se pitanje: kakav model usvojiti?
Dolazni tok poziva se mo`e smatrati homogenim ili nehomogenim Puasonovim tokom (tj. procesorski poslovi su nezavisni ili zavisni me|u sobom). Vreme usluge se mo`e smatrati da je slu~ajna veli~ina sa bilo kojom raspodelom. Jedino se na~in usluge uvek smatra da je sa ~ekanjem i sa neograni~enim brojem mesta za ~ekanje, ako se radi o relativno niskom optere}enju.
Sa ovakvim modelom procesor se mo`e prora~unavati u tri slu~aja: normalnom radu, sa preoptere}enjem i sa preoptere}enjem i uklju~enom ZOP.
50
SLIKA 6.1
Karakteristika propusnosti
6.1.1. Projektovani kapacitet komutacionog ure|aja
Pod radnom karakteristikom centralnog procesora se smatra zavisnost broja uspe{no obra|enih poziva u jedinici vremena (propusnost) od broja poziva u jedinici vremena ponu|enih procesoru na obradu [18] .
Efikasna strategija upravljanja preoptere}enjem }e spre~iti rapidni pad u obradi poku{aja poziva sa pove}anjem preoptere}enja (vidi krivu A na slici 6.1); postoji relativno mali pad, kod omogu}enog upravljanja preoptere}enjem (kriva C na slici 5.1), stoga {to je do{lo do pove}anja posla zbog samog sprovo|enja procesa upravljanja preoptere}enja.
Preoptere}enje se defini{e kao nivo poku{aja poziva ponu|enih komutacionom ure|aju koji prevazilazi projektovani kapacitet. Npr., kada su u komutacionom ure|aju ponu|eni poku{aji poziva za 10% ve}i od projektovanog kapaciteta, ka`e se da komutacioni ure|aj ima 10% preoptere}enja.
Propusnost komutacionog ure|aja na preoptere}enju od Y% iznad projektovanog kapaciteta optere}enja treba da bude najmanje X% od propusnosti pri projektovanom optere}enju. Ovaj koncept je prikazan na slici 6.2 koja pokazuje podru~je neprihvatljive performanse propusnosti. Prihvatljiva je bilo koja kriva propusnosti koja prolazi iznad X% nivoa do dostizanja ta~ke od Y%. Preporu~ene vrednosti su Y = 50% i X = 90%. Ispod Y% optere}enja komutacioni ure|aj treba da nastavi obradu poziva na prihvatljiv na~in.
Obra| enipoku{ajipoziva ujedinicivremena
Projektovana propusnost
B: maksimalna propusnost
C: sa upravljanjempreoptere}enja
A: bez upravljanjapreoptere}enja
Projektovani kapacitet Ponu| eno optere}enje(poku{aji poziva/jed.vrem.)
51
Sve dok nivo optere}enja ne prelazi Y% iznad projektovanog kapaciteta komutacionog ure|aja, tada propusnost komutacionog ure|aja treba da bude ne manja od X% od projektovanog kapaciteta, kao {to je nazna~eno na slici 6.2.
SLIKA 6.2
Karakteristika propusnosti
Na slici su prikazane radne karakteristike centralnog procesora jednog zami{ljenog komutacionog ure|aja (bez tranzitnih veza) u kojoj se 30% ponu|enih poziva ne ostvari zbog drugih razloga (pogre{no biranje, gubici u komutaciji i na ostalim organima, zauzet tra`eni, tra`eni odsutan). Na slici se vide radne karakteristike procesora u oblasti od nultog optere}enja do velikog preoptere}enja. Idealna karakteristika procesora sa ZOP prikazuje `elju da propusnost bar ne opada naglo u uslovima velikog optere}enja ako ve} ne mo`e da raste. Najzad, realna karakteristika procesora sa ZOP pokazuje stvarne mogu}nosti procesora. Delotvornost ZOP je obrnuto srazmerna uglu izme|u idealne i realne radne karekteristike. Razlika izme|u idealne i realne radne karakteristike je deo procesorskog posla koji je utro{en na sprovo|enje mera ZOP. Zbog toga se i kod najboljih ZOP idealna radna karakteristika ne mo`e dosti}i.
Komutacioni ure|aj treba da sadr`i odgovaraju}a sredstva za otkrivanje stanja preoptere}enja.
Po~etak stanja preoptere}enja treba da prepozna logika komutacionog ure|aja koja }e u stvari pokrenuti procese za izbegavanje te`ih degradacija u propusnosti. Za vreme preoptere}enja, pove}a}e se ka{njenja u obradi i prevazi}i }e se ciljne performanse date za referentno optere}enje B.
Obra| enipoku{ajipoziva ujedinicivremena
Projektovana propusnost
Maksimalna propusnost
Stvarna propusnost saupravljanjem preoptere}enja
Projektovani kapacitet Ponu| eno optere}enje(poku{aji poziva/jed.vrem.)
Neprihvatljiviregion
X %projektvanepropusnosti
Projektovani kapacitet+ Y %
52
Pokazatelji preoptere}enja mogu, na primer, da se obezbede kontinualnim merenjem zauzetosti resursa koji se koriste za obradu poziva tokom kratkih perioda (npr. nekoliko sekundi), nadgledanjem du`ine redova ~ekanja za razli~ite procese obrade poziva, itd.
6.2. Za{tita od preoptere}enja
Metode unutra{njeg upravljanja preoptere}enjem komutacionog ure|aja su zavisne od odre|enog tehni~kog ure|enja komutacionog sistema.
U cilju smanjenja optere}enja komutacionog ure|aja prouzrokovog pozivima koji ne mogu biti obra|eni za vreme preoptere}enja, mo`e biti neophodno obeshrabriti dalje poku{aje korisnika za vreme ove situacije.
Jednom primenjeno, upravljanje preoptere}enjem treba {to pre ukloniti kad se isto smanji, konzistentno sa potrebom izbegavanja oscilatornog pona{anja koje mo`e da produ`i period degradacije usluga.
Kao okvirne ideje za obezbe|ivanje usluga za vreme stanja preoptere}enja, primenjivi su slede}i op{ti principi:
• re|e uklju~ivanje ili potpuno isklju~ivanje nekih delova programa administracije i nadgledanja,
• davanje prednosti pozivima u toku obrade nad novim pozivima,
• davanje prednosti dolaznim vezama nad odlaznim,
• davanje prednosti prioritetnim korisnicima,
• odugovla~enje sa davanjem signala slobodnog biranja,
• neprihvatanje novih poziva.
• dati prvenstvo u obradi zavr{nim pozivima;
• dati prvenstvo vodovima prioritetnih klasa, pozivima ka prioritetnim odredi{tima zasnovanim na cifarskim analizama i dolaznim pozivima sa prisutnim pokazateljima prioriteta;
• odlo`iti neke ili sve aktivnosti koje nisu neophodne za obradu ponu|enog saobra}aja, na primer neke administrativne procese ili procese odr`avanja u komutacionom ure|aju ( to se ne odnosi na terminale za spregu operatera preko kojih se realizuju funkcije esencijalne za smanjenje preoptere}enja);
• nastaviti sa tarifiranjem i nadzorom, sve do prijema odgovaraju}ih osloba|aju}ih signala;
• dodeliti prioritete specifi~nim merenjima u komutacionom ure|aju, tako da se manje va`na merenja obustave na ni`em nivou zagu{enja.Merenja vi{eg
53
prioriteta se ili obustave na visokom nivou zagu{enja, ili se izvode neprekidno ako to zahteva njihova va`nost.;
Mere ZOP se mogu podeliti na nekoliko radnji. Utrvr|ivanje po~etka preoptere}enja se obavlja upore|ivanjem neke promenljive veli~ine koja pokazuje veli~inu optere}enosti i postavljenog praga. Promenljiva veli~ina mo`e biti broj procesorskih poslova na ~ekanju, du`ina vremena ~ekanja, saobra}aj procesora, intenzitet pozivanja. Prag za utvr|ivanje po~etka preoptere}enja mo`e biti utvr|eni ili promenljivi.
Uklju~ivanje mera ZOP obavezno po~inje svrstavanjem korisnika, poziva ili razgovora u nekoliko grupa razli~itog prava prvenstva na obradu. Jasno je da se prvo uklju~uju najbla`e mere.
Pra}enje delovanja mera mora biti obazrivo da bi se ceo proces za{titio od oscilacija. Zbog toga povratna sprega od otkrivanja i pra}enja preoptere}enja do primene mera mora biti odre|ena za svaku veli~inu komutacionog ure|aja.
Isklju~ivanje mera ZOP po prolasku preoptere}enja treba da bude izvedeno na takav na~in da sve bude spremno za novi talas preoptere}enja.
Poseban problem predstavljaju kratkotrajni skokovi optere}enja koji ne predstavljaju preoptere}enje ve} su posledica slu~ajnosti saobra}ajnog procesa. Ovi kratkotrajni skokovi u dobro izvedenoj ZOP ne smeju da pokrenu mere ZOP, jer komutacioni ure|aj i bez njih mo`e da savlada ove kratke udare. S druge strane pokretanje mera ZOP bi dovelo do nepotrebnih gubitaka. Ovde se, dakle, mora na}i ravnote`a izme|u brzine uklju~ivanja ZOP i gubitaka.
Osnovi zadatak ZOP je da pod uslovima preoptere}enja {to delotvornije iskoristi procesor, tj. da deo jalovog saobra}aja smanji na {to manju meru.
Osnovna osobina korisnika je da verovatno}a njihove odluke da napuste ~ekanje na uslugu raste sa porastom njihovog nestrpljenja, tj. sa porastom du`ine vremena ~ekanja na uslugu. Ova ~injenica je navela tvorce jednog od prvih na~ina ZOP da uvedu pravilo usluge po kome prvenstvo imaju korisnici sa kra}im vremenom ~ekanja. Ovo pravilo, ma koliko izgledalo nepravedno, daje dobre rezultate jer se najpre obra|uju noviji pozivi, tj. oni sa najmanjom verovatno}om odustajanja.
Jo{ jedna osobina korisnika je da mnogi od njih odustaju vrlo brzo ukoliko signal slobodnog biranja kasni. U ovom slu~aju tako|e veliki broj korisnika po~inje da bira `eljeni pozivni broj pre signala slobodnog biranja {to se opet svodi na odustajanje. Ove osobine pretplatnika su navele tvorce ZOP da procesorski posao oko jedne veze rasporede tako da je njegov {to manji deo vezan za fazu slobodnog biranja. Na taj na~in se smanjuje jalovi posao procesora u slu~aju ranog odustajanja ili prevremenog biranja.
Jedan od dobrih na~ina ZOP je da se svakom novom pozivu pripi{e odre|ena koli~ina procesorskog posla koji treba da bude obavljen do kraja veze. Kada je zbir predstoje}eg procesorskog posla ve}i od nekog praga novi poziv se odbacuje. U vremenu izme|u dolazaka poziva koli~ina predstoje}eg posla se smanjuje istom brzinom kojom ga procesor obavlja. Dobra strana ovog na~ina je u tome {to se mere ZOP ne uklju~uju kad nastupi zagu{enje ve} kada se ono predvi|a.
54
Jo{ jedan dobar na~in ZOP je brojanje novih poziva u odre|enom intervalu. Pozivi se ne prihvataju ako je broj poziva u predhodnom intervalu ve}i od praga p(y). Ovaj prag je promenljiv i zavisi isklju~ivo od optere}enja centralnog procesora y. Ovaj prag se tako|e pode{ava u odre|enim intervalima.
6.3. Metodologije za merenje kapaciteta centralnog procesora komutacionog ure|aja
Kapacitet komutacionog ure|aja se mo`e meriti simulacijom, u laboratoriji ili u eksploatacionim uslovima i mogu se napraviti projekcije radi predvi|anja najve}eg kapaciteta obrade [30]. Dalje }e se izlo`iti primer metodologije kojom je mogu}e izmeriti kapacitet obrade poziva u komutacionom ure|aju.
Kapacitet obrade poziva procesora se mo`e izraziti u terminima maksimalnog broja poziva (ili poku{aja poziva) koji mogu da budu obra|eni u zadatom vremenskom intervalu. U normalnim uslovima, radne funkcije koje obavlja procesor komutacionionog sistema se mogu podeliti u tri kategorije (jedna je stalnog nivoa a dve su promenjivog) kao {to je prikazano na slici 6.3.
SLIKA 6.3
Alokacija kapaciteta obrade
U slu~aju jednoprocesorskog sistema, slika 6.3 prikazuje kapacitet obrade komutacionog ure|aja [31]. U vi{eprocesorskom sistemu, kapacitet je raspore|en izme|u procesora i kapacitet komutacionog ure|aja zavisi od konfiguracije sistema pa je kapacitet
Procenat
100
90-95
Dodelaraspolo` ivogkapacitetaprocesora
Obrada naosnovnomnivou Obrada
poziva
Kapacitetrezervisan zavrhoveoptere}enja
Poku{ajipozivaStalni vi{ak posla
Optere}enje obrade
Kapacitet obradeprocesora
0
55
obrade komutacionog ure|aja funkcija procesora koji su uklju~eni u funkcije obrade poziva.
Kao {to je prikazano na slici 6.3 kapacitet obrade procesora je podeljen izme|u tri elementa:
1) neophodan posao vezan za obavezne zadatke (npr. raspore|ivanje zadataka i nadziranje);
2) posao obrade poziva
3) odlo`ivi zadaci (na osnovnom nivou) (npr. nadgledanje rutina)
Zadacima koje izvodi procesor su dodeljena tri nivoa prioriteta, osnovni, srednji i zadaci visokog nivoa.
a) Niski intenzitet saobra}aja b) Visok intenzitet saobra}aja
SLIKA 6.4.
Dodela procesorskog vremena zadacima
Pri normalnim optere}enjima, prime}uje se linearna zavisnost izme|u ponu|enog optere}enja i iskori{}enja procesora. Me|utim, pri velikim optere}enjima, neke sistemske komponente mogu da postanu preoptere}ene te ovo ima odraza u nelinearnosti zavisnosti iskori{}enja procesora od optere}enja.
Kako saobra}ajno optere}enje (poku{aji poziva) raste, {iri se posao obrade poziva, a obrada odlo`ivih zadataka se smanjuje.
Zadaci visokognivoa
Zadaci obradepoziva
Zadaciosnovnog nivoa
Sistemskiprekid
Sistemskiprekid
Sistemskiprekid
Sistemskiprekid
Vreme
Vremeosnovnog nivoa
Vreme
56
Merenje procenta vremena koje procesor provede obavljaju}i zadatke osnovnog nivoa daje indikaciju o kapacitetu obrade koji se zahteva za odre|eno optere}enje procesora.
Kako je prikazano na dijagramu a) slike 6.4, pri niskom saobra}ajnom optere}enju, procenat iskori{}enog vremena za izvo|enje zadataka osnovnog nivoa je relativno visok. Na dijagramu b) slike 6.4, pri visokom saobra}ajnom optere}enju, procenat vremena na niskom nivou je relativno nizak. Stoga se merenje procenta vremena utro{enog za obavljanje zadataka osnovnog nivoa mo`e da upotrebi za odre|ivanje kapaciteta obrade poziva.
Skup podataka }e zavisiti od sredstava raspolo`ivih za izvo|enje zahtevanih merenja. Komutacioni ure|aj mo`e da bude projektovan tako da obezbedi pokazatelje o utro{enom vremenu za obavljanje zadataka niskog nivoa ili mo`e biti neophodan pristup magistrali procesora sistema da bi se ovo vreme izmerilo. Bi}e neophodna oprema za proizvo|enje optere}enja, ili se u komutacionim ure|ajima u radu moraju izmeriti optere}enja da bi se uspostavili okviri optere}enja. Raznoliki nivoi optere}enja za razne tipove poziva (ili usluga) treba da se posmatraju da bi se uspostavila osnova za projektovanje linija optere}enja za odre|ivanje maksimalnog kapaciteta obrade za me{avinu saobra}ajnih usluga koje su pretpostavljene ili izmerene. Kod projektovanja kapaciteta poziva mora se obratiti pa`nja da se ne ekstrapolira iznad linearne oblasti zavisnosti iskori{}enja procesora nasuprot ponu|enim poku{ajima poziva.
SLIKA 6.5.
Merenje kapaciteta obrade
6.4. Indikatori performanse
Procenat
100
% vremena naosnovnomnivou
Vi{ak posla
Rezervnikapacitet
Poku{aji poziva
Projektovanikapacitet obrade
0
7050 Izmerene ta~ke optere}enja
• •• •
•• •
•
57
Iz prethodnog razmatranja se vidi da je pojam performanse {iroko kori{ten. Mo`e se re}i da nema jedinstvene definicije tog pojma. Umesto toga postoji ~itav niz pojmova koji se nazivaju indikatori performanse.
U preporuci ITU-T Q.543 [18] je definisan indikator performanse komutacionog ure|aja pod imenom referentni kapacitet procesorske jedinice (RKPJ) (engl., reference unit processing capacity - RUPC). RKPJ je ukupni broj poziva koji se mo`e obraditi procesor za vreme od jednog sata tako da komutacioni ure|aj zadovoljava saobra}ajne karakteristike (iz poglavlja 5) a u isto vreme obavljaju}i sve administrativne i nadzorne funkcije zahtevane za njegov normalni rad. U pomenutoj preporuci su dati obrasci kako se izra~unava ovaj kapacitet.
Me|utim, postavlja se klju~no pitanje:
• kakvu meru nam daje RKPJ kao indikator performanse?
Naime, ako se za jedan komutacioni ure|aj obavi merenje i izra~una RKPJ, tada se mo`e odgovoriti samo na jedno pitanje. A ono glasi: da li komutacioni ure|aj mo`e ili ne mo`e da zadovolji projektovani (`eljeni) kapacitet obrade. Dakle, izmereni, tj. izra~unati RKPJ daje jedan od slede}a dva odgovora:
• -a) komutacioni ure|aj mo`e da obradi `eljenu koli~inu poziva ili
• -b) komutacioni ure|aj ne mo`e da obradi `eljenu koli~inu poziva.
U ovom radu se nije `elelo zaustaviti na ovom mestu. Namera je da se dobije daleko finiji odgovor, odgovor sa ve}om rezolucijom. Ako komutacioni ure|aj mo`e da obradi `eljenu koli~inu poziva, neophodno je saznati koliko je za to utro{io svojih resursa, odnosno da li je, i koliko dodatnog posla jo{ mogao da obavi za to vreme? Mo`e se re}i da se na taj na~in dolazi do saznanja koliki deo od jednog zadatog vremenskog intervala procesor provede obra|uju}i pozive i sve {to ide uz to, a koliki deo od tog vremena procesor obra|uje pozive.
Stoga u ovom radu nije RKPJ ono do ~ega se `eli do}i egzaktnim merenjem. RKPJ ustvari predstavlja ulaznu veli~inu, tj. referencu u odnosu na koju se `eli do}i do novog kvaliteta u odgovoru na pitanje o performansi. Taj kvalitet se sadr`i u izmerenom utro{ku vremena potrebnog za doti~nu obradu.
Tako se te`i{te ispitivanja preme{ta sa
• bele`enja broja poziva
na
• merenje utro{ka vremena za njihovu obradu.
Tako se umesto RKPJ, kao indikator performanse mo`e postaviti utro{eno vreme [32] . Po{to se to utro{eno vreme uvek upore|uje sa ukupno proteklim vremenom, zaklju~uje se da sam apsolutni iznos nije taj koji se `eli iskazati ve} njegov udeo u zadatom intervalu merenja.
Na taj na~in je u ovom radu za INDIKATOR PERFORMANSE usvojen procenat iskori{}enja procesora, kao koli~nik izme|u korisnog vremena obrade i ukupnog vremena posmatranja, u procentima:
58
korisno vreme obrade
OPT = ______________________ * 100 [%] (6.1)
ukupno vreme posmatranja
Prelaz sa RKPJ na OPT kao indikator performanse nosi u sebi jednu zna~ajnu nepovoljnost. Merenje utro{ka vremena je znatno zahtevnija operacija od bele`enja broja poziva.
Merenje utro{enog vremena samo po sebi tro{i dosta procesorskog vremena, bez obzira na koji na~in se realizuje.
Na raspolaganju su uglavnom dve metode.
Jedna se zasniva na pribavljanju trenutnog vremena na po~etku merenog intervala i pribavljanju trenutnog vremena na kraju merenog intervala. Razlikom ovih dvaju vremenskih trenutaka se dobija ukupan utro{ak vremena. Me|utim, u radu programske podr{ke za realno vreme ovaj scenario se ne odvija tako glatko. Naime, nije procesor od po~etka do kraja pomenutog merenja uvek posve}en samo tom, merenom zadatku. Taj interval je "iseckan" radom zadataka vi{eg prioriteta. Za svaki taj prekid u merenju potrebno je obra~unati nepripadaju}i interval, tj. umanjiti kona~ni iznos za sve te intervale kad su obra|ivani zadaci vi{ih prioriteta. Po{to ovi prekidi mogu biti veoma kratki, javlja se opasnost od toga da je dodatni posao ovih korekcija u rangu izmerenih intervala, {to dovodi do nepreciznih rezultata merenja.
Kod druge metode za merenje utro{enog vremena nema asinhronih uzorkovanja po~etka i kraja intervala. Umesto toga celokupno vreme je izdeljeno na periodi~ne segmente, pa se merenje zasniva na prebrojavanju segmenata kada je doti~ni zadatak bio aktivan. I ova metoda mo`e da unosi veliku gre{ku zbog dodatnog posla ~iji se iznos ne vidi, po{to se njegov vremenski utro{ak neopravdano pripisuje objektu merenja. Osim toga, ova metoda krije u sebi mogu}nost jedne ozbiljnije gre{ke, a ona se doga|a pri nepovoljno odre|enom intervalu za period nadziranja aktivnosti poslova. Odre|ivanje ovog perioda je stvar osetljivog pode{avanja koje se mora uskladiti sa o~ekivanim trajanjem samih objekata merenja.
Mo`e se diskutovati kada je jedna od pomenutih metoda bolja od druge, ali je jasno da obe kriju u sebi mogu}nosti zna~ajnih gre{aka merenja. Stoga }e u ovom radu biti izlo`en metod indirektnog merenja vremena tako da se izbegnu pomenute opasnosti od prevelikog vi{ka posla [33], [34] .
Ova metoda se zasniva na jednostavnoj operaciji prebrojavanja i detaljno je obja{njena u ta~ki 6.5.
59
6.5. Realizacija predlo`ene metode merenja optere}enja procesora
Centralni procesor izvr{ava odgovaraju}i ra~unarski program specifi~an za njegove zadatke i polo`aj u hijerarhiji komutacionog ure|aja. U razli~itim vremenskim trenucima procesor izvr{ava razli~ite delove njegovog pripadaju}eg ra~unarskog programa, tako da se i kapacitet procesora raspodeljuje na izvr{avanje razli~itih zadataka.
Ukupan kapacitet procesora je raspodeljen na tri osnovne komponente:
1. Osnovna sistemska podr{ka (OSP) su osnovne funkcije i rutine koje su neophodne za rad komutacionog ure|aja (vremenske rutine, raspore|ivanje zadataka, prekidne rutine, komunikacione rutine, udvajanje i sinhronizacija). Ovo su zadaci sa najvi{im nivoom prioriteta {to zna~i da se njihovo izvr{avanje ne mo`e odlo`iti zbog zahteva za obradom bilo kog drugog nivoa, jer }e to dovesti da naru{avanja osnovnih postavki komutacionog ure|aja, t.j. do neizvr{avanja pojedinih faza obrade poziva ili ~ak i do naru{avanja ispravnosti rada ~itavog komutacionog ure|aja.
2. Funkcije obrade poziva (FOP) su funkcije analize, distribucije i rukovanja porukama i doga|ajima koji predstavljaju ekvivalente odgovaraju}ih faza obrade telefonskog poziva.
3. Funkcije Odr`avanja Nadzora i Operativnog Vo|enja (FONOV) obavljaju zadatke nadgledanja, dijagnostike, ispitivanja, merenja, prikupljanja statistike itd. Ovo su zadaci sa najni`im niovom prioriteta, jer njihovo odlaganje, pa ~ak i prekidanje, ne unose nestabilnost u funkcionisanje ~itavog sistema.
Optere}enje procesora se mo`e odrediti upravo na osnovu vremena koje on provede izvr{avaju}i zadatke najni`eg nivoa prioriteta, jer samim tim se zna preostali deo vremena koje procesor odvaja za izv{avanje zadataka obrade poziva. Merenjem procenta vremena koje procesor utro{i na zadatke najni`eg nivoa prioriteta dobija se uvid u veli~inu optere}enja procesora.
Raspodela procesorskog vremena na izvr{avanje pojedinih komponenti ra~unarskog programa je zavisna od broja poziva koji se u tom trenutku nalaze na obradi kao i od pojedinih faza u kojima se ti pozivi u tom trenutku nalaze, tj. od samog intenziteta telefonskog saobra}aja. Ukoliko procesor obra|uje manji broj poziva tada je i vreme procesora utro{eno na obradu tih poziva manje, a vi{e vremena preostaje za zadatke niskog prioriteta (rutine odr`avanja), nasuprot tome kada procesor obra|uje ve}i broj poziva, zadacima niskog prioriteta ostaje manje vremena.
Koraci u odre|ivanju optere}enja procesora su slede}i:
1. Odredi se vreme koje je procesoru potrebno za izvr{avanje zadataka najvi{eg niova prioriteta
2. Odredi se projektovani maksimalni kapacitet (broj poziva kada se celokupno procesorsko vreme utro{i na zadatke 1. i 2. tako da nakon toga za svaku dodatnu obradu dolazi do naru{avanja ispravnosti obrade poziva i gubitka pojedinih faza poziva)
Na osnovu relacije:
60
TCIKLUS = TOSP + TFOP + TFONOV (6.2)
gde je:
TCIKLUS - osnovni interval nadgledanja (merenja),
TOSP - vreme utro{eno za osnovnu sistemsku podr{ku,
TFOP - vreme utro{eno za funkcije obrade poziva,
TC=FONOV - vreme utro{eno za funkcije odr`avanja, nadzora i operativnog vo|enja.
Rukovode}i se time, nakon odre|ivanja vremena TFONOV i TOSP dobija se:
TFOP = TCIKLUS - TOSP TFONOV - (6.3)
Ovako odre|eni intervali vremena daju osnovu za odre|ivanje indikatora performanse, izra~unavaju}i odnos izme|u utro{enog vremena za obradu poziva zajedno sa neophodnim vremenom za osnovnu sistemsku podr{ku (TFOP + TOSP) i ukupnog utro{enog vremena (TCIKLUS ).
TFOP + TOSP
OPT = ___________ * 100 [%] (6.4)
TCIKLUS
Po{to su u predhodnoj ta~ki (6.4) obrazlo`eni problemi koji se mogu javiti pri odre|ivanju ovih veli~ina, u ovom radu je predlo`ena indirektna metoda merenja utro{ka vremena.
Su{tina ove metode je da se umesto merenja vremena bele`i broj pojavljivanja niza relevantnih doga|aja. Ovo bele`enje se obavlja u okviru jednog intervala merenja TCIKLUS .
Za pomenute relevantne doga|aje se uzimaju izvr{enja jedne instrukcije procesora sa zadate memorijske lokacije u okviru programske podr{ke. Sama ta instrukcija je ustvari uve}avanje za jedan promenljive koja predstavlja broja~ za merenje. Veoma je va`no da se dobro izabere pomenuta memorijska lokacija. U slu~aju da je programska podr{ka organizovana tako da na svakom prioritetu postoji jedan zadatak koji se sigurno ponavlja u intervalu TCIKLUS , i ako on ima cikli~ni tok, {to je i naj~e{}i slu~aj, tada se za pomenutu lokaciju odabira jedna ta~ka u okviru toka, npr. na njegovom kraju.
61
Kada se za svaki ciklus merenja dobiju vrednosti broja~a, jasno je da su ovi broja~i me|u sobom korelirani, kao {to bi bili korelirani apsoluni iznosi vremena pojedinih zadataka. Korelacija ovih veli~ina je ilustrovana na slici 6.6.
TCIKLUS
TOSP = nOSP * tOSP
tTFOP = nFOP * tFOP TFONOV = nFONOV * tFONOV
Slika 6.6 Korelacija apsolutnih vremena i vrednosti broja~a pojedinih zadataka
gde je:
nOSP - vrednost broja~a za osnovnu sistemsku podr{ku,
nFOP - vrednost broja~a za funkcije obrade poziva,
nFONOV - vrednost broja~a za funkcije odr`avanja, nadzora i operativnog vo|enja.
Odre|ivanje utro{enog vremenskog perioda na izvr{avanje zadataka OSP se obavlja u odsustvu poruka za obradu poziva kao i u uslovima deaktiviranih zadataka FONOV:
tOSP = TCIKLUS /nOSP (6.5)
Ovo vreme odgovara relativno nultom optere}enju (u pogledu na broj poziva, tj. kada je broj poziva jednak nuli) odnosno vrednost apsolutnog optere}enja koje odgovara nultom relativnom optere}enju. Dakle, vrednost nOSP se preslikava u optere}enje od 0 procenata.
Slede}i korak predstavlja odre|ivanje vrednosti broja~a za maksimalni projektovani kapacitet obrade poziva, uz `eljeni rezervni kapacitet. Ovo merenje se sprovodi uz pomo} odgovaraju}eg simulatora kojim se generi{e projektovani saobra}aj. Na taj na~in se odre|uje utro{eno vreme za puni kapacitet rada:
TFOPmax = nOSP TCIKLUS - (tOSP *nOSP + tFONOV* nFONOV) (6.6)
ili
62
TFOPmax = tFOPmax *nFOPmax (6.7)
gde je nFOPmax vrednost broja~a za projektovani kapacitet.
Ovo vreme odgovara relativno potpunom optere}enju (u pogledu na broj poziva, tj. za maksimalni broj poziva) odnosno vrednost apsolutnog optere}enja koje odgovara relativnom punom optere}enju. Dakle, vrednost nFOPmax se preslikava u optere}enje od 100 procenata.
U radnim uslovima je:
TFOP = TCIKLUS - (tOSP *nOSP + tFONOV* nFONOV) (6.8)
odnosno
TFOP = tFOP *nRAD (6.9)
gde je nRAD vrednost broja~a za proizvoljne radne uslove.
Ako se obezbedi umesto tri razli~ita broja~a jedan jedini broja~, takav da je sme{ten u deo programske podr{ke koji se uvek izvr{ava, zna~i u petlju pozadinskog procesa, tada se mogu sva tri broja~a (nOSP, nFOPmax, nRAD) preslikati u jedan broja~. Pozicioniranje ovog objedinjenog broja~a u pozadinski proces odgovara njegovom pozicioniranju u FONOV deo programske podr{ke. Ovakav izbor nije u~injen slu~ajno, po{to nije svejedno da li broja~ staviti u OSP/FOP deo ili u FONOV deo programske podr{ke. Razlog le`i u ~injenici da je programska podr{ka tako projektovana da se FONOV zadaci potiskuju iz procesa obrade (zbog njihovog najni`eg prioriteta). Stoga se posti`e efekat da u periodima kad se broja~ ne uve}ava, merenje se i dalje odvija, uz najbolji sporedni efekat - sam taj posao ne upo{ljava procesor - odnosno, nema dodatnog vi{ka posla, tako neugodno prisutnog kod ranije opisanih metoda za odre|ivanje apsolutnog utro{ka vremena. Zna~i, ukupno utro{eno vreme za ovo merenje ne uti~e na vreme rada zadataka vi{ih prioriteta. Kad bi broja~ bio u delu programske podr{ke koja je zadu`ena za poslove OSP ili FOP, utro~ak vremena procesora za merenje bi se odvijao na visokom prioritetu - zna~i na u{trb ukupnog vremena za obradu poziva. Na kraju, ali ne manje zna~ajno treba ista}i da je sama metoda indirektnog merenja neuporedivo kra}a od bilo koje metode apsolutnog merenja vremena. Razlog za to je su{tinski - postoji samo jedna promenljiva, i jednom instrukcijom uve}anja za jedan
63
se obavi svako uzorkovanje. Kod apsolutnih metoda, radi se o stotinama instrukcija potrebnih za uzimanje odbiraka vremena, odnosno za pretra`ivanje spregnutih lista od raznih zadataka, tj. funkcija koje se moraju obuhvatiti merenjem.
Jedinstveni broja~ }e za gore navedene uslove rada predstavljati nOSP, kada su isklju~eni FONOV poslovi, zatim }e predstavljati nFOPmax, kada su obezbe|ena maksimalna saobra}ajna optere}enja, a u radnim uslovima taj broja~ predstavlja nRAD.
Sada je mogu}e pristupiti merenju optere}enja u realnim uslovima, dakle bez simulatora. Zahvaljuju}i ranije izmerenim vrednostima broja~a nFOPmax i nOSP , a na osnovu izmerene teku}e vrednosti broja~a odre|uje se relativno radno optere}enje .
Prema izlaganju u ta~ki 6.1, odnosno saglasno ITU-T preporukama Q.543, za o~ekivati je da i ovaj indikator performanse pokazuje linearnu zavisnost u najve}em delu svog opsega. Ovakav zaklju~ak se je logi~an zbog ~injenice da linearno pove}anje broja poslova, zbog pove}anja broja poziva, ima za posledicu linearno pove}anje vremena potrebnog za obradu istih.
Linearna zavisnost optere}enja od broja poziva ustvari odgovara linearnoj zavisnosti optere}enja od vrednosti broja~a. Op{ti oblik linearne zavisnosti je
y = a * x + b (6.10)
Ako se na apscisu postave vrednosti broja~a, a na ordinatu izra~unato opere}enje, onda jedna~ina (6.10) izgleda ovako:
OPT = a * nRAD + b (6.11)
Dakle, potrebno je odrediti vrednosti koeficijenata a i b. Do njih se dolazi na osnovu grani~nih uslova rada, kao {to je opisano gore. To su uslovi za maksimalno i minimalno optere}enje. Tada su eksperimentalno odre|ene vrednosti za nOSP i nFOPmax. Prema tome dobija se sistem od dve linearne jedna~ine sa dve nepoznate:
koordinata maks. optere}enja: MAX(100, nFOPmax): 100 = a * nFOPmax + b (6.11) koordinata min. optere}enja: MIN(0, nOSP): 0 = a * nOSP + b (6.12)
Iz ove dve jedna~ine se dobije da je
a = 100/(nFOPmax - nOSP) (6.13)
64
i
b = 100 * nOSP /(nOSP - nFOPmax) (6.14) tako da je
nOSP - nRAD
OPT [%] = 100 * ‡‡‡‡‡‡‡‡‡‡‡‡‡ (6.15)
nOSP - nFOPmax
gde je nRAD nezavisno promenljiva iz jedna~ine (6.10) i predstavlja vrednost broja~a u posmatranom periodu merenja u uslovima realnog saobra}aja.
6.6. Jedan primer realizacije metode merenja optere}enja procesora
Radi merenje indikatora performanse procesora u komutacionom ure|aju izabrana je slede}a konfiguracija (slika 6.7):
Slika 6.7 Konfiguracija za merenje
Po{to se celokupni saobra}aj od N korisnika svodi na protok na primarnom pristupu - PRI, radi ve}e fleksibilnosti u postupku merenja je kori{tena ispitna
KORISNI^ KIISDN
PRIKLJU^ AK
KOMUTACIONIURE\ AJ
(ISDN KOMUTACIJA)
1
2
.
.
.N
PRI
65
konfiguracija sa slike 6.8. Ovde je umesto stvarnog saobra}aja od strane N korisnika upotrebljen posebno razvijeni simulator poziva.
Slika 6.8 Ispitna konfiguracija sa simulatorom
U komutacionom ure|aju je za obradu poziva zadu`ena programska podr{ka za digitalnu korisni~ku signalizaciju broj jedan (engl., Digital Subscriber Signalling System No. 1 - DSS 1), te je radi testiranja primarnog pristupa DSS1 razvijen simulator koji obezbe|uje slede}e funkcije:
• Uspostavu, odr`avanje i raskidanje govornih veza pomo}u DSS1 signalizacije na primarnom pristupu.
• Ubacivanje govornih informacija u jedan od 30 kanala.
Simulator radi na bazi formirane datoteke. Datoteka pobude mo`e biti formirana na dva na~ina i to:
• generisanjem pobude matemati~kim modelom sistema ili
• snimanjem optere}enja na sistemu u radu
Kao ulazni parametri za formiranje modela se uzimaju slede}e veli~ine:
• gomilanje (B)
• srednje optere}enje po korisniku (asr )
• srednje vreme trajanja poziva (hsr )
Na osnovu ovih parametara i slede}ih jedna~ina se odre|uje ukupno optere}enje na primarnom pristupu od centrale ka ra~unaru sa primarnim DSS1 pristupom. i mogu se
SIMULATORPOZIVA
KOMUTACIONIURE\ AJ
(ISDN KOMUTACIJA)
PRI
66
generisati vrednosti po Poissonovom procesu za po~etke poziva i za trajanje poziva po negativno eksponencijalnoj raspodeli.
Koriste}i ovako modeliran saobra}ajni proces, formira se simulaciona datoteka koja ima slogove prema slede}em formatu:
Vreme Komanda Kanal Tip Broj pretplatnika t START k VOICE N
Vreme: broj otkucaja sata realnog vremena u simulatoru brzine 10ms Komanda: START po~etak veze STOP kraj veze Kanal: po kom kanalu primarnog pristupa se odvija komunikacija Tip: VOICE prenos govornih informacija u kanalu Broj pretplatnika: Ozna~ava ko je pozivaju}i u komunikaciji
Najpre je potrebno snimiti stanje broja~a za uslove odsustva svih zadataka najni`eg prioriteta (FONOV) kao i odsustva bilo kog saobra}aja na snopu, tj. zadataka FOP. Tako se dobije vrednost:
nOSP = 27305
Da bi se snimila vrednost broja~a za maksimalno optere}enje uzete su slede}e vrednosti ulaznih parametara:
• B = 0,1 %
• hsr = 60 sekundi
• asr = 1 E
• Auk = 30 E
• trajanje simulacije 3600 sekundi
Na taj na~in se dobila vrednost
67
nFOPmax = 24228
Sada se mo`e obaviti merenje za jedan skup ulaznih podataka variraju}i broj poziva u toku simulacije prema slede}oj tabeli:
poziv/sat 486 774 906 1740 1902 3594 4488 6918 8274
nRAD 26150 26088 25925 25741 25700 25291 25196 24870 24480
Ako se broj poziva svede na interval od jedne sekunde dobija se slede}a tabela:
poziv/sek 0,135 0,215 0,252 0,483 0,528 0,998 1,246 1,922 2,298
nRAD 26150 26088 25925 25741 25700 25291 25196 24870 24480
Sada se na osnovu izraza (6.15) dobiju vrednosti indikatora performanse OPT, {to je prikazano u narednoj tabeli:
poziv/sat 486 774 906 1740 1902 3594 4488 6918 8274 poziv/sek 0,135 0,215 0,252 0,483 0,528 0,998 1,246 1,922 2,298
nRAD 26150 26088 25925 25741 25700 25291 25196 24870 24480
OPT[%] 37,54 39,55 44,88 50,83 52,16 65,45 68,54 79,28 91,63
Ako se dobijene vrednosti prika`u grafi~ki dobiju se linearne zavisnosti indikatora performanse OPT od vrednosti broja~a, odnosno od broja poziva u jedinici vremena, {to se vidi na graficima 6.1 do 6.3.
Ovim je eksperimentalno potvr|ena ispravnost pretpostavke prema izlaganju u ta~ki 6.1, odnosno saglasno ITU-T preporukama Q.543, tj. pokazano je da je indikator performanse pokazuje linearnu zavisnost u najve}em delu svog opsega za ovu primenu. Ovakav zaklju~ak je logi~an zbog ~injenice da linearno pove}anje broja poslova, zbog pove}anja broja poziva, ima za posledicu linearno pove}anje vremena potrebnog za obradu istih u podru~ju znatno ispod stvarnog kapaciteta procesora.
U ovom primeru maksimalno optere}enje koje je zadato procesoru (na osnovu kojeg je odre|ena vrednost nFOPmax) ne predstavlja apsolutno najve}e optere}enje koje bi taj procesor mogao da podnese. Ovde to predstavlja relativno najve}e optere}enje, tj. najve}e optere}enje za tu aplikaciju. Specifi~nost doti~ne aplikacije je ograni~ila opseg optere}enja. U navedenom opsegu pokazuje se ispravnost pretpostavke o linearnoj zavisnosti.
Istom metodom se mo`e realizovati merenje i za slu~aj kada se primeni apsolutno mogu}e maksimalno optere}enje
68
69
Optere}enje procesora
0
10
20
30
40
50
60
70
80
90
100
240002450025000255002600026500
Broj prolazaka (obrade)
Opt (%)
Grafik 6.1 Zavisnost indikatora performanse (OPT) od vrednosti broja~a( nRAD)
70
Optere}enje procesora
0
10
20
30
40
50
60
70
80
90
100
0 1000 2000 3000 4000 5000 6000 7000 8000 9000
Broj poziva u satu
Opt (%)
Grafik 6.2 Zavisnost indikatora performanse (OPT) od broja poziva u satu
71
Optere}enje procesora
0
10
20
30
40
50
60
70
80
90
100
0 0,5 1 1,5 2 2,5
Broj poziva u sekundi
Opt (%)
Grafik 6.3 Zavisnost indikatora performanse (OPT) od broja poziva u sekundi
72
Poglavlje 7
7. ZAKLJU^AK
U procesu izgradnje komutacionih ure|aja (centrala) zna~ajno mesto zauzima projektovanje, implementacija, pode{avanje i odr`avanje programske podr{ke koja se nalazi u njihovom upravlja~kom delu [35].
Predmet istra`ivanja ovog rada je ispitivanje ove programske podr{ke, {to pretpostavlja specifi~ne postupke koji proisti~u iz posebnih uslova u kojima ovakvi programi rade, jer se radi o radu u realnom vremenu. Stoga se proces ispitivanja prostire u okviru svih etapa izrade ove programske podr{ke.
7.1. Pregled rezultata istra`ivanja
Na po~etku je izlo`ena koncepcija otvorenih sistema, tj. referentni OSI model po{to se on mo`e koristiti kao referentni model bilo koje mre`e. Ovakva koncepcija referentnog modela je iskori{tena za definisanje slede}eg modela u procesu ispitivanja, a to je uporedni model. On predstavlja osnovu za analiziranje logi~ke korektnosti i usagla{enosti stvarne implementacije sa specifikacijom protokola. Uporedni model se defini~e pomo}u nekog formalizovanog oblika specificiranja, a to je naj~e{}e SDL, tj, jezik za specificiranje i opisivanje. SDL se zasniva na modelu automata sa kona~nim brojem stanja. SDL dijagrami opisuju logi~ku strukturu programa, njegov dinami~ki tok, a istovremeno se vide i svi skupovi ulaznih i izlaznih propmenljivih, kao i stanja sistema zajedno sa skupom uslova.
Definisani uporedni model predstavlja referencu za ispitivanje usagla{enosti koje se obavlja pomo}u sistematizovanog skupa testova organizovanih u grupe testova sa propisanim koracima testova i doga|ajima u okviru svakog koraka testa. Navedeni postupak je primenjen u okviru ispitivanja usagla{enosti programske podr{ke protokola nivoa 3 dela za prenos poruka u Sistemu signalizacije broj 7, kako je definisano u ITU-T preporuci Q.782.
73
Da bi se realizovao uporedni model, kao i za potrebe intervencija na ispitivanoj programskoj podr{ci kori{}en je poseban alat - CTOSDL. Uz pomo} ovog alata se mo`e dobiti SDL dijagram iz programskog koda, mogu se obaviti intervencije na dijagramu i na kraju, kao najva`nija mogu}nost je ubacivanje proizvoljnih funkcija na izabrana mesta u SDL, odnosno u samu realizovanu programsku podr{ku.
Ubacivanje proizvoljnih funkcija na ovaj na~in je naro~ito pogodno za potrebe umetanja ispitnih ta~aka radi snimanja relevantnih podataka iz ciljnih doga|aja kod svakog koraka testa.
Tako se umesto zamornog procesa analize protokola i ru~nog menjanja izvornog testa programske podr{ke, radi umetanja funkcija za nadzor i ispitivanje, proces svodi na grafi~ku interakciju sa SDL dijagramom i pogodnom bibliotekom nadzornih funkcija.
Upotreba CTOSDL programskog alata se ne ograni~ava samo na proces izgradnje uporednog modela i ispitivanje usagla{enosti, ve} se koristi i u drugim vrstama ispitivanja koja su opisana u ovom radu:
• prikupljanje saobra}ajnih podataka komutacionog ure|aja
• merenje performanse komutacionog ure|aja
U oba pomenuta postupka neophodno je u kona~nu, verifikovanu verziju programske podr{ke ugraditi nove merne ta~ke, odnosno dodati pogodne funkcije za ostvarenje tih zadataka. Realizacija ovih zahteva se efikasno mo`e ostvariti uz pomo} programskog alata CTOSDL na ranije opisanim principima.
Vi{e puta istaknuta specifi~nost programske podr{ke za komutacione ure|aje ogleda se i u potrebi za pro{irenjem pojma ispitivanja. Pored ispitivanja usagla{enosti neophodno je uvesti metode za ispitivanje dinami~kih karakteristika rada ovih sistema kao {to su ispitivanja vezana za merenje saobra}aja i prikupljanje statisti~kih podataka. Ova ispitivanja predstavljaju grani~nu oblast izme|u ispitivanja ispravnosti rada i ispitivanja pode{enosti (performanse) sistema. Na osnovu pokazatelja dobijenih u okviru ovih ispitivanja mogu}e je sagledati eventualnu potrebu za boljim re{enjima na planu same programske podr{ke.
Te`i{te ispitivanja u okviru magistarske teze je stavljeno na zavr{na ispitivanja programske podr{ke. To su ispitivanja iz faze pode{avanja projektovanog i implementiranog sistema. U ova ispitivanja spada odre|ivanje performanse procesora zadu`enog za rad upravlja~kog dela komutacionog sistema.
Za reprezentativni pokazatelj performanse komutacionog ure|aja je umesto referentnog kapaciteta procesorske jedinice - RKPJ (iz ITU-T preporuke Q.543) definisan procenat iskori{}enja procesora, kao koli~nik izme|u korisnog vremena obrade i ukupnog vremena merenja, u procentima. Tako se umesto podatka o broju poziva u intervalu jednog sata koje mo`e da obradi posmatrani procesor u komutacionom ure|aju, odnosno ~injenice da li je mogu}e obraditi `eljeni kapacitet saobra}aja ili ne, na osnovu novouvedenog indikatora performanse mo`e odrediti koliko je za to utro{io svojih resursa, odnosno da li je, i koliko dodatnog posla jo{ mogao da obavi za to vreme.
74
Stoga u ovom radu RKPJ ustvari predstavlja ulaznu veli~inu, tj. referencu u odnosu na koju se `eli do}i do novog kvaliteta u odgovoru na pitanje o performansi. Taj kvalitet se sadr`i u izmerenom utro{ku vremena potrebnog za doti~nu obradu.
Tako se te`i{te ispitivanja preme{ta sa bele`enja broja poziva na merenje utro{ka vremena za njihovu obradu. Radi smanjenja udela inherentne gre{ke merenja, umesto apsolutnog utro{ka vremena u radu je predlo`ena metoda indirektnog merenja vremena. Ustvari pokazuje se da sam iznos vremena nije ni bitan jer se indikator defini{e kao odnos korisnog dela prema ukupnom utro{ku. Tako se do{lo do minimalne metode koja se svodi na bele`enje vrednosti prostog broja~a koji je postavljen na pogodno mesto u okviru programske podr{ke.
Na kraju je pokazana primena predlo`ene metode na primeru ispitivanja indeksa performanse programske podr{ke za digitalnu korisni~ku signalizaciju DSS1.
7.2. Mogu}i pravci daljih istra`ivanja
Na osnovu postignutih reazultata u opisanim metodima prirodno proisti~u i pravci daljeg rada i istra`ivanja u oblasti pra}enja ispravnosti rada programske podr{ke u realnom vremenu.
Zahvaljuju}i sprovedenoj analizi i predlo`enim modelima vezanim za ispitivanje usagla{enosti implementacije, mogu}e je pro{iriti oblast primene programskog alata za interakciju programske podr{ke i SDL dijagrama u domen objektno orjentisanih programskih jezika, tj. mogu}e je pre}i na sa jezika C na C++.
U okviru problema prikupljanja saobra}ajnih i statisti~kih podataka postoji ~itav niz pravaca rada koji se mogu definisati. Oni se mogu grupisati u obalsti merenja saobra}aja na organima, na oblast statisti~kih pokazatelja i na merenje saobra}aja na signalnim kanalima. Dobar deo ovih merenja je u radu definisan i realizovan, pa je potrebno obraditi neke slu~ajeve koji nisu pokriveni. To su, na primer klase statisti~kih podataka vezanih za brojanje poziva vezanih za specijalne usluge, zatim intenziteti saobra}aja unutar komutacionog ure|aja i sli~no [36], [37], [38].
Metodu merenje optere}enja procesora, kao jednog predstavnika indikatora performanse, treba pro{iriti u oblasti primene drugih koncepcija programske podr{ke, osim pozadinske petlje. Tada je neminovno reaktiviranje metode direktnog merenja utro{ka vremena u pojedinim zadacima obrade poziva, funkcija nadzora, administracije kao i osnovne sistemske podr{ke. Kao neko srednje re{enje trebalo bi istra`iti mogu}nost primene metode brojanja programskih instrukcija, jer je za optere}enje procesora kao indikator performanse prirodno najbli`a definicija da je to srednji broj instrukcija po pozivu.
75
Kori{}ena literatura
[1] Fred Halsall, Data Communications, Computer Networks and OSI, Addison-Wesley, 1988.
[2] Gregor. Bochman, G. W. Gerber, J.-M. Serre, Semiautoimatic Implementation of Communication Protocols, IEEE Transactions on software engineering, vol. SE-13, No 9, september 1987.
[3] ITU-T Recommendation Z.100: CCITT Specification and Description Language (SDL), 1994
[4] ITU-T Recommendation X.208: Abstract Symbol Notation No. 1 (ASN.1) - Basic Notation, 1994
[5] Thomas Drake, Measuring Software Quality: A Case Study, Computer, IEEE, November 1996
[6] H. Kopetz, G. Grünsteidl, TTP - A Protocol for Fault-Tolerant Real-Time Systems, Computer, IEEE, Januar 1994
[7] Leonard Kleinrock, Queueing Systems, John Wiley and Sons, Inc., 1976.
[8] Telelogic Tau SDT 3.1 Getting started
[9] Telelogic Tau SDT 3.1 Methodology guidelines
[10] ITU-T Recommendation X.290 , OSI conformance testing methodology and framework for protocol Recommendations for ITU-T applications – General concepts, 1995
[11] John D. Musa, Softvare Reliability Engineered Testing, Computer November 1996
76
[12] Alan Wood, Predicting Softvare Reliability, Computer November 1996
[13] Nikola Tesli}, Jedno re{enje uskopojasne centrale sa integrisanim slu`bama, Magistarski rad, Novi Sad 1997.
[14] ITU-T Recommendation Q.782 , Signalling System No. 7, MTP Level 3 Test Specification, 1994
[15] ITU-T Recommendation Q.704 , Specifications of Signalling System No. 7, Message Transfer Part Signalling Network Functions and Messages, 1994
[16] ITU-T Recommendation Q.707 , Specifications of Signalling System No. 7, Testing and Maintenace, 1994
[17] Nikola Nikoli}, Jedno re{enje modifikacije SDL dijagrama, Diplomski rad, Novi Sad 1995.
[18] ITU-T Recommendation Q.543, Digital Exchange Performance Design Objectives, 1994
[19] Prof. dr. Slavko Svir~evi}, Teorija telefonskog saobra}aja, interna dokumentacija.
[20] Prof. dr. Stanislav Mati}, Principi komutacije u telekomunikacijama, JP PTT Srbija, Beograd 1993.
[21] Gordana Jovanovi}-Dole~ek, Sluajne varijable i procesi u telekomunikacijama, Svjetlost, Sarajevo 1987.
[22] Redmill F. J., Valdar A. R. : SPC Digital Telephone Exchanges, Peter Peregrinus, London, 1990.
[23] Slavko Svir~evi}, Vladimir Kova~evi}, Miroslav Popovi}, Kvantitativna analiza telefonske centrale vi{eg hijerarhijskog nivoa, TELFOR 1993, Beograd.
77
[24] Slavko Svir~evi}, Vladimir Kova~evi}, Miroslav Popovi}, New Concept of Digital Exchange, Proc. International Workshop on Information Technologies, System Control and System Management, Novi Sad 1994.
[25] @eljko Jurca, Zoran Kraja~evi}, Izbor re{enja me|uprocesorske komunikacije u CVHN, ETRAN, Zlatibor, jun 1995.
[26] @eljko Jurca, Darko. Veselinovi}, Ispitivanje ispravnosti delova CVHN, ETRAN, Zlatibor, jun 1995.
[27] @eljko Jurca, Sonja Vukobrat, Zdravko Manojlovi}, I{tvan Torda, Re{enje merenja saobra}aja i optere}enja procesora u CVHN-RT , ETRAN,1997
[28] D.-S. Lee, S.-Q. Li, Transient analysis of a switched Poisson arrival queue under ovreload control, Preformance Evaluation 17, Elsevier Science Pub.vol. 17, Januar 1993
[29] S. Haldar, D. K. Subramanian, An affinity-based dynamic load balancing protocol for distributed transaction processing systems, Preformance Evaluation 17, Elsevier Science Pub.vol. 17, Januar 1993
[30] Goran Kruni}, Neboj{a Rado{evi}, Vladimir Kova~evi}, Procena kapaciteta obrade poziva RPKST-a i CP-a u CVHN simulacijom pomo}u simulacionog paketa NETWORK II.5, XXXIX Konferencija za ETRAN, Zlatibor , 1994.
[31] I{tvan Torda, @eljko Jurca,Andra{ \etvai, Merenje optere}enja procesora u CVHN, ETRAN 1996
[32] @eljko Jurca, Jasmina Pavlovi}, Jedno re{enje pra}enja performanse CVHN-a merenjem vremena izvr{enja programske komponente, TELFOR 1995
[33] @eljko Jurca, Vladimir Kova~evi}, I{tvan Torda, An approach to testing of real time software and control of switchig system performance, International Conference on System Science, Wroclav, Poland, 1995.
[34] @eljko Jurca, I{tvan Torda, Vladimir Kova~evi}, The method for testing of real time software, Relectronic 1995, Budapest.
78
[35] Kornel Terplan, Communication Networks Management, Prentice-Hall, Inc., 1987.
[36] Trevor Housley, Data Communications & Teleprocessing Systems, Prentice-Hall, Inc., 1987.
[37] Fred Jennings, Practical Data Communications, Scientific Publications, 1986.
[38] D. W. Davies, Computer Networks and their Protocols, John Wiley and Sons, Inc., 1986.
79
PRILOG 1:
P1.1 Kori{}enje programa CTOSDL
Pri pokretanju programa iscrtava se ekran prikazan na slici P1.1. Ekran se sastoji iz horizontalnog menija, radne povr{ine, strelica za kretanje po virtuelnom ekranu, i radnog prozora.
Slika P1.1. Osnovni ekran programa CTOSDL
Radna povr{ina je deo virtuelnog ekrana. Virtuelni ekran je matrica od 32767 32767× polja, pri ~emu svako polje mo`e da sadr`i najvi{e jedan simbol. Sva polja su fiksne veli~ine od 120 24× ta~aka, {to omogu}ava preglednost dijagrama.
80
Zbog veli~ine, nije mogu} istovremeni prikaz celog virtuelnog ekrana, ve} se on posmatra kroz “prozor” tj., kroz radnu povr{inu. Navedeni princip je prikazan na slici P1.2. Strelicama za kretanje po virtuelnom ekranu se omogu}ava kretanje po ekranu, odnosno pomeranje radne povr{ine. Korak kretanja se mo`e pode{avati {to }e kasnije biti obja{njeno. 0 32767 0 0 4 0 32767 17
Slika P1.2. Princip pregledanja virtuelnog ekrana
Radni prozor je povr{ina prikazana na slici P1.3., na koju se ispisuju slede}e informacije:
• naziv datoteke koja se obra|uje, • naziv funkcije ~iji je SDL dijagram nacrtan.
Slika P1.3. Radni prozor
81
Horizontalni meni, kao {to se vidi na slici P1.4., sadr`i slede}e opcije:
• FILE - obuhvata uglavnom opcije za rukovanje datotekama, • FUNCTION - sadr`i opciju LIST, koja slu`i za izbor funkcije ~iji se
dijagram `eli prikazati, • LIBRARY - sadr`i opciju INCLUDE, koja slu`i za odre|ivanje biblioteke
iz koje }e se vr{iti izbor funkcija predvi|enih za ubacivanje u izvorni kod programa,
• OPTION - sadr`i opcije za pode{avanje okru`enja, pretra`ivanje i opciju za vra}anje na predhodni korak rada,
• INSERT - obuhvata opcije vezane za modifikovanje SDL dijagrama i ubacivanje novih funkcija u izorni kod programa.
Opcije iz navedenog horizontalnog menija se pozivaju pritiskom levog tastera mi{a na odre|enu opciju. Pri tom se otvara odgovaraju}i vertikalni meni sa podopcijama. Kada se pozove opcija FILE horizontalnog menija, otvara se vertikalni meni prikazan na slici P1.4., koji sadr`i slede}e opcije:
• LOAD - izborom ove opcije u~itava se i obra|uje datoteke koja sadr`i deo izvornog koda programa,
• SAVE - navedena opcija slu`i za snimanje izmena obavljenih na teku}em SDL dijagramu,
• PROJECT - ovom opcijom se odabiraju projektne datoteke programa ~iji se SDL dijagram `eli prikazati,
• polje koje sadr`i ime teku}e projektne datoteke koja se analizira, • About... - daje osnovne informacije o programskom paketu CTOSDL, • EXIT - omogu}ava izlazak iz programa CTOSDL.
Slika P1.4. Vertikalni meni FILE
Izborom FUNCTION opcije horizontalnog menija otvara se vertikalni meni samo sa jednom opcijom, tj. opcijom LIST, koja slu`i za izbor funkcije ~iji se SDL dijagram `eli prikazati.
82
Izborom LIBRARY opcije horizontalnog menija, otvara se vertikalni meni prikazan na slici P1.5. Vertikalni meni sadr`i opcije:
• INCLUDE - ova opcija slu`i za odre|ivanje biblioteke iz koje }e se odabirati funkcije predvi|ene za ubacivanje u izvorni kod programa,
• polje koje sadr`i naziv datoteke (biblioteke) iz koje }e se odabirati funkcije predvi|ene za ubacivanje u izvorni kod programa.
Slika P1.5. Vertikalni meni LIBRARY
Pozivom OPTION opcije horizontalnog menija, otvara se vertikalni meni prikazan na slici P1.6. Navedeni vertikalni meni sadr`i slede}e opcije:
• STEP - ova opcija menija slu`i za pode{avanje koraka pregledanja virtuelnog ekrana,
• UNDO - izborom ove opcije omogu}ava se vra}anje na predhodni korak rada,
• COLORS - navedena opcija omogu}ava pode{avanje boja na ekranu, • SEARCH - omogu}ava pretra`ivanje po SDL dijagramu funkcije koja se
obra|uje, odnosno tra`enje zadatog niza znakova.
Slika P1.6. Vertikalni meni OPTION
83
Izborom INSERT opcije horizontalnog menija otvara se vertikalni meni prikazan na slici P1.7., koji sadr`i slede}e opcije:
Slika P1.7. Vertikalni meni INSERT
• SIMBOL - omogu}ava ubacivanje simbola SDL dijagrama iznad ozna~enog mesta na dijagramu,
• CODE - izborom ove opcije omogu}ava se ubacivanje programskog koda u izvorni kod programa,
• Delbegin - ovom opcijom se ozna~ava mesto od koga }e se brisati simboli iz dijagram,
• DelEnd - navedenom opcijom se ozna~ava mesto do koga }e se brisati simboli sa dijagram,
• REPLACE - omogu}ava zamenu postoje}eg simbola (ozna~enog) drugim, • MODIFY - ovom opcijom se vr{i modifikacija dijagrama za programske
strukture if i switch-case.
Pod pode{avanjem okru`enja se podrazumeva pode{avanje slede}ih parametara:
• pode{avanje boja na ekranu, • zadavanje koraka kretanja po virtuelnom ekranu, • odre|ivanje biblioteke iz koje }e se vr{iti izbor funkcija predvi|enih za
ubacivanje u izvorni kod programa.
84
Pode{avanje boja se vr{i izborom COLORS opcije u vertikalnom meniju OPTION prikazanom na slici P1.6. Nakon poziva navedene opcije sekvencijalno se otvaraju prozori konstrukcije prikazane na slici P1.8. pomo}u kojih se pode{avaju slede}i elementi ekrana:
a) PAPER - podloga prozora,
b) DESKTOP - radna povr{ina,
c) INK - boja osnovnog ispisa,
d) INK2 - boja ispisa 2,
e) INK3 - boja ispisa 3,
f) BACK - pozadina,
g) SHADOW - senke prozora. @eljena boja se bira prema nazivu boje uz pomo} mi{a i pritiskom na softverski taster OK.
Korak kretanja po virtuelnom ekranu se pode{ava pozivom STEP stavke vertikalnog menija INSERT sa slike P1.6. Pozivom ove opcije otvara se editorski prozor prikazan na slici P1.9. U prozoru se nalazi polje u kome se mo`e modifikovati korak u intervalu od 0 do 99 simbola po ekranu. Kada se unese `eljeni korak pritiskom na ENTER se zatvara editorski prozor.
Slika P1.8. Pode{avanje boja
Slika P1.9. Unos koraka
85
P2.1 OFF-LINE modifikacija Program CTOSDL omogu}ava ubacivanje programskog koda na zadato mesto u SDL dijagramu. Da bi se omogu}ilo ubacivanje ta~no odre|enog skupa funkcija, uvodi se programska biblioteka, kao datoteka, iz koje se is~itavaju i ubacuju definisane funkcije. Inicijalno, program ~ita biblioteku STANDARD.H. Da bi se to promenilo potrebno je pozvati opciju INCLUDE vertikalnog menija LIBRARY . Pozivom ove stavke iscrtava se prozor prikazan na slici P1.10. U navedenom prozoru se ispisuju nazivi svih datoteka sa ekstenzijom .H iz teku}eg direktorijuma. Softverskim strelicama vr{i se kretanje po listi, dok se bibliotek bira pritiskanjem levog tastera mi{a na `eljeno ime datoteke.
Po{to se odabere odgovaraju}a biblioteka pritiskom na softverski taster OK zatvara se prozor.
Operacije na SDL dijagramu su realizovane kao posebne opcije u vertikalnom meniju INSERT sa slike P1.7. Da bi izvr{ili neku operaciju nad `eljenim simbolom dijagrama, potrebno je prvo markirati (obele`iti) simbol. To se ostvaruje pritiskom desnog tastera mi{a na `eljeni simbol {to se kasnije manifestuje kao promena boje selektovanog simbola.
Brisanje skupa simbola SDL dijagrama se vr{i u slede}im koracima:
a) Markira se simbol od koga }e se po~eti brisati simboli.
b) U vertikalnom meniju INSERT (slika P1.7.) se izabere stavka DelBegin, {to prouzrokuje da markirani simbol promeni boju.
c) Markira se simbol do kog }e se izvr{ti brisanje. Pri tom se markirani simbol ne bri{e.
d) U vertikalnom meniju INSERT (slika P1.7.) se izabere stavka DelEnd, nakon ~ega dolazi do promene boje markiranog simbola.
Ovim koracima je obele`en deo dijagrama koji se `eli obrisati, dok se sama promena mo`e ostvarati snimanjem izmena uz pomo} opcije SAVE vertikalnog menija FILE sa slike P.4.
Slika P1.10. Izbor biblioteke
86
Primer brisanja dela dijagrama sa slika P1.11.a. i P1.11.b. se mo`e relizovati obele`avanjem simbola kao {to je prikazano na slici P1.11.a. Snimanjem izmena dobija se dijagram sa slike P1.11.b.
Ubacivanje nekog simbola u SDL dijagram se vr{i u slede}im koracima:
a) Markira se simbol ispred koga se `eli ubaciti novi.
b) U vertikalnom meniju INSERT (slika P1.7.) se izabere stavka SIMBOL , pri ~emu se pojavljuje prozor sa slike P1.12.
(a) (b)
Slika P1.11. Brisanje dela dijagrama
c) Iz dobijenog prozora se mi{em izabere simbol koji se `eli ubaciti. Iscrtava se editorski prozor sa slike P1.13.
d) Preko tastature se unese niz znakova koji }e biti upisan u simbol SDL dijagrama i pritisne se ENTER.
Ovim koracima je obele`eno mesto na dijagramu gde se `eli ubaciti simbol, dok se sama promena mo`e ostvarati snimanjem izmena uz pomo} opcije SAVE vertikalnog menija FILE sa slike P1.4.
-->
87
Primer ubacivanja simbola za slanje poruke se mo`e relizovati obele`avanjem simbola kao {to je prikazano na slici P1.14.a. Snimanjem izmena dobija se dijagram sa slike P1.14.b.
(a) (b)
Slika P1.14. Ubacivanje simbola u SDL dijagram
Slika P1.13. Upisivanje naziva simbola
Slika P1.12. Izbor simbola
-->
88
Zamena nekog simbola SDL dijagrama drugim se obavlja u slede}im koracima:
a) Markira se simbol koji se `eli zameniti.
b) U vertikalnom meniju INSERT se izabere stavka REPLACE , {to prouzrokuje pojavljivanje prozora sa slike P1.12.
c) Iz dobijenog prozora se mi{em izabere simbol kojim se `eli zameniti teku}i simbol, tako da se zatim iscrtava editorski prozor sa slike P1.13.
d) Pomo}u tastature se unese niz znakova koji }e biti upisan u simbol SDL dijagrama.
Navedenim koracima je obele`eno mesto na dijagramu gde se `eli izvr{iti zamena, dok se sama promena mo`e ostvarati snimanjem izmena.
Zamena simbola SDL dijagrama se mo`e relizovati obele`avanjem simbola kao {to je prikazano na slici P1.15.a. Snimanjem izmena dobija se dijagram sa slike P1.15.b.
(a) (b)
Slika P1.15. Zamena simbola SDL dijagrama
⇒⇒⇒⇒
89
Slo`ena modifikacija if selekcije se obavlja u slede}im koracima:
a) Ozna~i se simbol selekcije (tip 5) ili simbol slanja poruke (tip 2).
b) U vertikalnom meniju INSERT se izabere stavka MODIFY , {to prouzrokuje pojavljivanje prozora sa slike P1.16.
c) Iz dobijenog prozora se mi{em odabere transformacija koja se `eli uraditi, tako da se zatim iscrtava editorski prozor sa slike P1.13.
d) Pomo}u tastature se unese niz znakova koji }e biti upisan u simbol SDL dijagrama.
Snimanjem izmena se dobija transformisani dijagram.
Izmena SDL dijagrama se mo`e realizovati obele`avanjem simbola kao {to je prikazano na slici P1.17.a. Snimanjem izmena dobija se dijagram sa slike P1.17.b.
Slika P1.16. Izbor modifikacije za if selekciju
90
(a) (b)
Slika P1.17. Modifikacija SDL dijagrama u slu~aju if selekcije
Switch-case struktura se mo`e modifikovati u slede}im koracima:
a) Markira se simbol grananja ili simbol ulaska u automat.
b) U vertikalnom meniju INSERT se izabere stavka MODIFY , {to prouzrokuje pojavljivanje prozora sa slike. U prozoru se ispisuju slede}e stavke:
states - selekcija stanja,
messages - selekcija poruka.
c) Iz dobijenog prozora se mi{em odabere transformacija koja se `eli uraditi.
Snimanjem izmena se dobija transformisani dijagram.
-->
91
Modifikovanje SDL dijagramse mo`e realizovati obele`avanjem simbola kao {to je prikazano na slici P1.21.a. Snimanjem izmena dobija se dijagram sa slike P1.21.b.
(a) (b)
Slika P1.21. Modifikacija SDL dijagrama u slu~aju switch-case strukture
Slika P1.19. Simbol ulaska u automat
Slika P1.18. Simbol grananja
Slika P1.20. Izbor modifikacije switch-case strukture
⇒⇒⇒⇒
92
P3.1 Ubacivanje programskog koda
Ubacivanje programskog koda se obavlja u slede}im koracima:
a) Uz pomo} mi{a odabira se simbol ispred koga se `eli ubaciti kod.
b) U vertikalnom meniju INSERT se odabere opcija CODE, {to prouzrokuje pojavljivanje dva prozora prikazanih na slici P1.22. U gornjem prozoru se mo`e, u pomo} tastera ⇓, izabrati funkcija koja se `eli ubaciti u kod. Donji prozor je editorski, {to zna~i da se u njemu direkno upisuje programski kod koji se `eli ubaciti.
c) Pomo}u tastera ⇓ se odabere programska funkcija.
d) Pomo}u tastature se u editorskom prozoru unese kompletna programska linija koja se `eli ubaciti u izvorni kod.
e) Pritiskom na taster ESC, zatvaraju se navedeni prozori i otvara dijalog prozor sa slike P1.23. Dijalog prozor sadr`i slede}e stavke:
yes - izborom ove opcije ubacuje se programski kod,
no - ova opcija prouzrokuje izlaz bez ubacivanja koda,
reform - navedena opcija omogu}ava povratak na editorski prozor i ponovno ubacivanje programske linije.
Ako se odabere stavka yes zatvaraju se prozori sa slike P1.23. i dijalog prozor. Posle toga odabrani simbol promeni boju.
Slika P1.22. Unos programskog koda
Slika P1.23. Dijalog prozor
Primer ubacivanja programskog koda se mo`e videti na slici P1.24. U ovom slu~aju je uba~ena programska funkcija ubacena_fu(). Slika P1.24.a. predstavlja prvobitni kod, dok slika P1.24.b. dobijeni kod nakon ubacivanja funkcije. Obele`avanje
93
mesta ubacivanja koda i izgled modifikovanog SDL dijagrama se vidi sa slika P1.24.c i P1.24.d. respektivno.
obrada__1_;
obrada__2_;
obrada__3_;
obrada__4_;
obrada__5_;
obrada__6_;
obrada__7_;
(a) (b)
.
(c) (d)
Slika P1.24. Ubacivanje programskog koda
Kako je ranije navedeno, veli~ina virtuelnog ekrana je 32767 32767× simbola. Zbog veli~ine, nije mogu} istovremeni prikaz celog virtuelnog ekrana, ve} se on posmatra kroz radnu povr{inu. Radna povr{ina se mo`e pomerati uz pomo} strelica za pomeranje po virtuelnom ekranu. Ovim je ostvaren uvid u kompletan virtuelni ekran.
obrada__1_;
obrada__2_;
obrada__3_;
ubacena_fu();
obrada__4_;
obrada__5_;
obrada__6_;
obrada__7_;
⇒⇒⇒⇒
94
^esto se de{ava da se odre|eno stanje pojavljuje vi{e puta na istom SDL dijagramu. Da bi se omogu}ilo brzo pronala`enje nekog stanja, ili bilo kog niza znakova, uvedena je mogu}nost pretra`ivanja SDL dijagrama.
Pretra`ivanje SDL dijagrama se vr{i na osnovu zadatog niza od najvi{e deset znakova. Pri tom se pretra`uje samo SDL dijagram funkcije koja se analizira.
Program CTOSDL omogu}ava dva na~ina tra`enja:
a) Tra`enje niza znakova od po~etka virtuelnog ekrana.
b) Pretra`ivanje od poslednje na|ene pozicije zadatog niza znakova.
Postupak pretrage za oba na~ina se obavlja u slede}im koracima:
a) Pozove se podopcija SEARCH vertikalnog menija OPTIONS {to prouzrokuje pojavljivanje editorskog prozora sa slike P1.25.
Slika P1.25. Editorski prozor za tra`enje niza znakova
b) Pomo}u tastature se unese niz znakova koji se `eli na}i. Pritisne se ENTER, pri ~emu da se pojavi dijalog prozor prikazan na slici P1.26. Dijalog prozor sadr`i slede}e softverske tastere:
Find - tra`enje niza znakova od po~etka virtuelnog ekrana,
Again - pretra`ivanje od poslednje na|ene pozicije zadatog niza
znakova,
Cancel - odustajanje od pretrage.
Slika P1.26. Dijalog prozor za tra`enje niza znakova
95
c) Odabere se `eljeni softverski taster, {to aktivira proces pretrage.
U slu~aju da se nadje `eljeni niz znakova, radna povr{ina se pomera. Dobijeni simbol, koji sadr`i zadati niz, locira se u gornji levi ugao ekrana. Ako se zadati niz ne na|e, pojavljuje se prozor prikazan na slici P1.27.
Slika P1.27. Izve{taj o neuspe{nom tra`enju
96
PRILOG 2
P2.1. Formati poruka merenja saobra}aja
Formati poruka :
a)
F
01111110 CK SIF SIO - LIO FIB FSN BIB BSN F
01111110
8 16 8xn 8 2 6 1 7 1 7 8 bita
b)
F
01111110 CK SIF - LIO FIB FSN BIB BSN F
01111110
8 16 8 2 6 1 7 1 7 8 bita
c)
F
01111110 CK - LIO FIB FSN BIB BSN F
01111110
8 16 2 6 1 7 1 7 8 bita
Gde je :
F - me|a, ozna~ava po~etak i kraj poruke ( engl. flag ) ( da ne bi do{lo do pojave la`ne me|e uvodi se za{tita, sadr`aj poruka se ispituje na predajnom kraju tako {to se tra`i vi{e od 5 uzastopnih jedinica, i u tom slu~aju se ubaci nula ),
CK - polje provere okvira (CHECK ),
SIF polje signalne informacije (SIGNALING INFORMATION FIELD ),
SIO - polje informacije o slu`bi (SERVICE INFORMATION)
SF - pokazatelj stanja (STATE FLAG ),
97
LIO - pokazatelj du`ine u okviru polja SIF i SIO u bajtovima (LENGTH INDICATOR),
FIB - pokazatelj poruke unapred (FORWARD INDICATOR BIT),
FSN - broj poruke unapred (FORWARD SIGNAL NUMBER),
BIB - pokazatelj poruke unazad (BACKWARD INDICATOR BIT),
BSN - broj poruke unazad (BACKWARD SIGNAL NUMBER).
FORMIRAJ_MER (TER->OR)
Sadr`i kompletnu strukturu podataka MS_rec koja sadr`i sve informacije za jedno merenje saobra}aja :
typedef struct {
int id; /* logicki broj merenja */
int objekat_merenja; /*0 = Snop
1 = Podsnop
2 = KS grupa
3 = KS podgrupa
4 = KS vod */
uchar stanje_merenja; /* 0 = ne formirano
1 = ceka merenje
2 = merenje u toku
3 = merenje odbijeno
4 = merenje obavljeno */
uchar int_ispisa; /* interval ispisa
0 = 15 min
1 = 30 min
2 = 1 sat
3 = 3 sata
4 = 6 sati
5 = 12 sati
6 = 24 sata */
uchar trajanje; /* trajanje merenja ( isti skup kao int_ispisa ) */
uchar tip_merenja; /* definisani tip merenja :
98
0 = Samo jedan dan
1 = Nedelju dana periodicno
2 = Mesec dana periodicno
3 = Mesec dana ( odredjeni dan u nedelji )
4 = Periodicno odredjeni (zadati) broj dana
5 = Trenutno aktiviranje */
uint broj_dana; /* vazi za periodican tip merenja */
struct date datum_pocetka; /* datum pocetka merenja */
struct time vreme_pocetka; /* vreme pocetka merenja */
uchar broj_snopova; /* broj snopova( ili podsnopova, ili grupa
ili podgrupa ili KS vodova na kojima se merenje
sprovodi */
uchar osn_interval[MAXSNOPMER]; /* osnovni interval uzimanja uzoraka za
svaki od definisanih snopova u okviru
snopovi[] :
0 = 3,6 sekundi
1 = 36 sekundi */
uint broj_skan[MAXSNOPMER]; /* interval_ispisa/osn_interval[i] */
uchar snopovi[ MAXSNOPMER ]; /* niz internih brojeva snopova */
uchar podsnopovi[MAXSNOPMER]; /* niz internih brojeva podsnopova */
uchar vodovi[MAXSNOPMER]; /* niz internih brojeva vodova */
/* niz internih brojeva (slucajevi) :
snop = snopovi[]
podsnop = snopovi[] + podsnopovi[]
grupa = snopovi[]
podgrupa= snopovi[] + podsnopovi
vod = snopovi[] + podsnopovi[] + vodovi */
} MS_rec;
99
FORMIRAJ_POT (OR->TER)
FORMIRAJ_ODB (OR->TER)
ZAHTEV_MER (OR->CP)
Format poruke:
kod
merenja
objekat merenja
interval ispisa
broj snopova
osnovni interval uzimanja uzoraka
interni broj objekta
1 1 1 1 broj snopova
Gde je:
kod merenja = identifikacioni bajt za odre|eno merenje iz intervala 0-(MAXMER-1))
objekat merenja = merenje saobra}aja se mo`e sprovoditi na :
0 = Snop
1 = Podsnop
2 = KS grupa
3 = KS podgrupa
4 = KS vod
interval ispisa = vremenski interval u kojem CP {alje OR-u rezultate merenja (porukama IZVESTAJ_REZ) i mo`e imati slede}e vrednosti:
0 = 15 min
1 = 30 min
2 = 1 sat
3 = 3 sata
4 = 6 sati
5 = 12 sati
6 = 24 sata
broj snopova = ukupan broj objekata merenja na kojima je zahtevano merenje saobra}aja
osnovni interval uzimanja uzoraka = vremenski interval u kojem se o~itavaju stanja objekata merenja (na CP-u)
0 = 3,6 sekundi
1 = 36 sekundi
100
interni broj objekta merenja = ovo polje mo`e biti promenljive du`ine:
objekat : tip du`ina sadr`aj
snop 1 interni broj snopa
podsnop 2 interni brojevi snopa+podsnopa
vod 3 interni brojevi snopa+podsnopa+voda
grupa 1 interni broj grupe
podgrupa 2 interni broj grupe+podgrupe
ZAHTEV _POT (CP->OR)
Polja u poruci: kod merenja (1)
ZAHTEV _ODB (CP->OR)
Polja u poruci: kod merenja (1)
MERENJE_ REZ (CP->OR)
Format poruke:
kod merenja
interni broj snopa
MSRez_od_CP_rec
1 1 4*8=32
Gde je:
kod merenja = identifikacioni bajt za odre|eno merenje iz intervala 0-(MAXMER-1))
Struktura MSRez_od_CP_rec je slede}eg oblika:
/* podaci za JEDAN SNOP u okviru jednog merenja od CP-a ka OR-u */
typedef struct {
uint broj_kanala;
uint blokirani;
ulong suma;
} snop_smer_podgrupa_od_CP; /* duz=8 */
/* MSRez_rec_od_CP je poruka rezultata od CP-ka OR-u */
typedef struct {
101
snop_smer_podgrupa_od_CP jodlaz;
snop_smer_podgrupa_od_CP jdolaz;
snop_smer_podgrupa_od_CP dvodlaz;
snop_smer_podgrupa_od_CP dvdolaz;
} MSRez_od_CP_rec; /* duz = 32 */
typedef MSRez_od_CP_rec *MS_od_CP_ptr;
KRAJ_MER (OR->CP)
Polja u poruci: kod merenja(1) (postoji mogu}nost istovremenog postojanja vi{e aktivnih merenja)
ZAHTEV_ZAGL (TER->OR)
Polja u poruci: kod merenja (1)
IZVESTAJ_ZAGL (OR->TER)
Polja u poruci: struktura MS_rec
ZAHTEV_REZ (TER->OR)
Polja u poruci:
kod merenja interni broj snopa
1 1
IZVESTAJ_REZ (OR->TER)
Format poruke:
kod merenja
interni broj snopa
broj poslatih blokova
MSRez_rec
1 1 1 64*broj poslatih blokova
Gde je:
kod merenja = identifikacioni bajt za odre|eno merenje iz intervala 0-(MAXMER-1))
broj poslatih blokova = broj blokova rezultata koji se nalaze u obliku strukture MSRez_rec slede}eg oblika:
102
/* svaka adtoteka sadr`i podatke za JEDAN SNOP u okviru jednog merenja */
typedef struct {
uint broj_kanala;
uint blokirani;
ulong suma;
float intenzitet;
float gomilanje;
} snop_smer_podgrupa; /* duz=16 */
/* MSRez_rec je najmanja jedinica informacije u datoteci rezultata za
jedan snop */
typedef struct {
snop_smer_podgrupa jodlaz;
snop_smer_podgrupa jdolaz;
snop_smer_podgrupa dvodlaz;
snop_smer_podgrupa dvdolaz; /* polja intenzitet i gomilanje se ne koriste
u okviru dvdolaz jer su identicna kao za
dvodlaz ( isto kao i broj_kanala i
blokirani ) */
} MSRez_rec; /* duz = 64 */
IZVESTAJ_REZ_POT (TER->OR)
Format poruke:
kod merenja
interni broj snopa
1 1
BRISANJE_MER (TER->OR)
Polja u poruci: kod merenja (1)
BRISANJE_POT (OR->TER)
Polja u poruci: kod merenja (1)
103
P2.2. Formati poruka za merenje signalnog saobra}aja
FORMIRAJ_MER (TER->OR)
Sadr`i kompletnu strukturu podataka MSIG_rec koja sadr`i sve informacije za jedno merenje signalnog saobra}aja :
typedef struct {
int id; /* logicki broj merenja */
uchar stanje_merenja; /* 0 = ne formirano
1 = ceka merenje
2 = merenje u toku
3 = merenje odbijeno
4 = merenje obavljeno */
uchar trajanje; /* trajanje merenja ( vidi u MERENJE.H ) */
uchar tip_merenja; /* definisani tip merenja :
0 = Samo jedan dan
1 = Nedelju dana periodicno
2 = Mesec dana periodicno
3 = Mesec dana ( odredjeni dan u nedelji )
4 = Periodicno odredjeni (zadati) broj dana
5 = Trenutno aktiviranje */
uint broj_dana; /* vazi za periodican tip merenja */
struct date datum_pocetka; /* datum pocetka merenja */
struct time vreme_pocetka; /* vreme pocetka merenja */
uchar broj_sigkanala; /* broj signalnih kanala na kojima se merenje sprovodi */
uchar osn_interval[MAXSIGKAN]; /* osnovni interval uzimanja uzoraka za svaki od definisanih signalnih kanala u okviru broj_sigkanala */
uchar sigkanali[ MAXSIGKAN]; /* niz internih brojeva signalnih kanala */
104
} MSIG_rec;
FORMIRAJ_POT (OR->TER)
FORMIRAJ_ODB (OR->TER)
ZAHTEV_MER (OR->CP)
kod
merenja
broj signalnih kanala
osnovni interval uzimanja uzoraka
interni broj signalnog kanala
1 1 broj signalnih kanala
Gde je:
kod merenja=identifikacioni bajt za odre|eno merenje iz intervala 0- (MAXMER-1)),
broj signalnih kanala = ukupan broj signalnih kanala na kojima je zahtevano merenje signalnog saobra}aja,
'broj signalnih kanala' puta se ponavljaju slede}a dva bajta:
osnovni interval uzimanja uzoraka = vremenski interval u kojem se OR-u {alu rezultati merenja (porukama IZVESTAJ_REZ) i mo`e imati slede}e vrednosti:
0 = 10sekundi
1 = 1 minut
2 = 15 minuta
3 = 30 minuta
4 = 1 sat
interni broj signalnog kanala = broj koji identifikuje signalni kanal (odnosno regionalni procesor i njegov 32-kanalni link tj. PCM)
ZAHTEV _POT (CP->OR)
Polja u poruci: kod merenja (1)
ZAHTEV _ODB (CP->OR)
Polja u poruci: kod merenja (1)
MERENJE_ REZ (CP->OR)
Polja u poruci:
105
kod merenja
interni broj signalnog kanala
MSIGrez_od_CP_rec
1 1 24
Gde je:
kod merenja = identifikacioni bajt za odre|eno merenje iz intervala 0-(MAXMER-1)
Struktura MSIG_rez_od_CP_rec je slede}eg oblika:
typedef struct {
ulong pos_bajt;
ulong pos_por;
ulong pos_ret;
ulong prim_bajt;
ulong prim_por;
ulong prim_ret;
} MSIG_rez_od_CP_rec; /* duz=24 */
KRAJ_MER (OR->CP)
Polja u poruci: kod merenja(1) (postoji mogu}nost istovremenog postojanja vi{e aktivnih merenja)
ZAHTEV_ZAGL (TER->OR)
Polja u poruci: kod merenja (1)
IZVESTAJ_ZAGL (OR->TER)
Polja u poruci: struktura MSIG_rec
ZAHTEV_REZ (TER->OR)
Format poruke:
kod merenja
interni broj signalnog kanala
106
1 1
IZVESTAJ_REZ (OR->TER)
Format poruke:
kod merenja
interni broj signalnog kanala
broj poslatih blokova
MSIG_rez_rec
1 1 1 28*broj poslatih blokova
Gde je:
kod merenja = identifikacioni bajt za odre|eno merenje iz intervala 0-(MAXMER-1))
broj poslatih blokova = broj blokova rezultata koji se nalaze u obliku strukture MSIG_rez_rec slede}eg oblika:
typedef struct {
ulong pos_bajt;
ulong pos_por;
ulong pos_ret;
ulong prim_bajt;
ulong prim_por;
ulong prim_ret;
float Aob;
} MSIG_rez_rec; /* duz=28 */
IZVESTAJ_REZ_POT (TER->OR)
Format poruke:
kod merenja
interni broj signalnog kanala
1 1
BRISANJE_MER (TER->OR)
Polja u poruci: kod merenja (1)
107
BRISANJE_POT (OR->TER)
Polja u poruci: kod merenja (1)
P2.3.Format poruka za prikupljanje statistike
Rezultati prikupljanja statisti~kih podataka su formirani u obliku 3D matrica broja~a (3DM) koja predstavlja trodimenzionalnu matricu, kod koje su vektori :
vektor 1: interni brojevi izvora,
vektor 2: interni brojevi odredi{ta,
vektor 3: interni brojevi poruka.
primer: ukoliko se primi poruka tipa 6 upu}ena iz izvora 3 ka odredi{tu 2 tada }e se inkrementirati 3DM(3,2,6) elemenat (broja~) u matrici.
FORMIRAJ_MER (TER->OR)
Sadr`i kompletnu strukturu podataka STAT_rec koja sadr`i sve informacije za jedno prikupljanje statisti~kih podataka:
typedef struct
{
uchar id; /* logicki broj merenja */
uchar stanje_merenja; /* 0 = ne formirano
1 = ceka merenje
2 = merenje u toku
3 = merenje odbijeno
4 = merenje obavljeno */
uchar trajanje; /* iste vrednosti kao i u MERENJE.H */
uchar tip_merenja; /* definisani tip merenja :
0 = Samo jedan dan
1 = Nedelju dana periodicno
2 = Mesec dana periodicno
3 = Mesec dana ( odredjeni dan u nedelji )
108
4 = Periodicno odredjeni (zadati) broj dana
5 = Trenutno aktiviranje */
uchar broj_dana; /* vazi za periodican tip merenja */
struct date datum_pocetka; /* datum pocetka merenja */
struct time vreme_pocetka; /* vreme pocetka merenja */
uchar osn_interval; /* osnovni interval ispisa CP->OR (MSIG.H) */
uchar brizvora; /* broj izvora */
uchar brodredista; /* broj odredista */
uchar brporuka; /* broj poruka */
uchar izvori[MAX_IZVOR][MAX_KAR_BR]; /* karakteristicni brojevi izvora
( cifre pakovane u obliku
'telefonskih'' brojeva : po cetiri
bita za cifru i niz cifara se
zavrsava sa 1111 ( 0x0F ) */
uchar tip_izvora[MAX_IZVOR]; /* tip izvora :
snop = 0
sig.tacka = 1 */
uchar odredista[MAX_ODRED][MAX_KAR_BR];/* karakteristicni brojevi odredista */
uchar poruke[MAX_PORUKA]; /* indeksi poruka (H0H1) */
} STAT_rec;
FORMIRAJ_POT (OR->TER)
FORMIRAJ_ODB (OR->TER)
ZAHTEV_MER (OR->CP)
Format poruke:
kod
merenja
osnovni interval uzimanja uzoraka
broj izvora
broj odredi{ta
broj poruka
izvori tip izvora
odredi{ta poruke
1 1 1 1 1
109
Gde je:
kod merenja = identifikacioni bajt za odre|eno merenje iz intervala 0-(MAXMER-1))
osnovni interval uzimanja uzoraka = periodi~an vremenski interval u kojem CP {alje OR-u rezultate a mo`e imati slede}e vrednosti:
0 = 10sekundi
1 = 1 minut
2 = 15 minuta
3 = 30 minuta
4 = 1 sat..
broj izvora = ukupan broj izvora od kojih se prikupljaju poruke
broj odredi{ta = ukupan broj odredi{ta ka kojima se posmatraju poruke od interesa
broj poruka = ukupan broj poruka koje se prikupljaju.
izvori = niz karakteristi~nih brojeva izvora (jedan karakteristi~an broj sadr`i maksimalno 8 4-bitno kodiranih cifara tj. du`ina jednog karakteristi~nog broja je 4 bajta)
tip izvora = ova informacija ima zna~aja ukoliko je izvor od koga primamo poruke na{ sused' tj. postoji direktan snop izme|u dva komutaciona ure|aja;
0 = Snop (mogu}e je posmatrati sve poruke koje su do{le po tom zajedni~kom snopu (bez obzira da li je 'sused' bio samo tranzit za njih ili su te poruke inicirane od 'suseda') slu~aj u praksi: ti komutacioni ure|aji koji su povezani sa susedom su starog tipa i nemaju mogu}nost slanja svoje identifikacije)
1 = Signalna ta~ka( samo poruke koje su potekle od 'suseda').
odredi{ta = niz karakteristi~nih brojeva odredi{ta
poruke = niz bajtova koji predstavljaju kodove zaglavlja odre|enih poruka (H0H1).
ZAHTEV _POT (CP->OR)
Polja u poruci: kod merenja (1)
ZAHTEV _ODB (CP->OR)
Polja u poruci: kod merenja (1)
MERENJE_ REZ (CP->OR)
Format poruke:
110
kod merenja
rezultati
1
Gde je:
kod merenja = identifikacioni bajt za odre|eno merenje iz intervala 0-(MAXMER-1)
rezultati = niz 16-bitnih broja~a (od MAX_IZVOR*MAX_ODRED*MAX_PORUKA elemenata)koji predstavljaju 3d matricu rezultata (uvek se {alje fiksan broj bajtova bez obzira na broj definisanih izvora, poruka i rezultata)
KRAJ_MER (OR->CP)
Polja u poruci: kod merenja(1) (postoji mogu}nost istovremenog postojanja vi{e aktivnih merenja)
ZAHTEV_ZAGL (TER->OR)
Polja u poruci: kod merenja (1)
IZVESTAJ_ZAGL (OR->TER)
Polja u poruci: struktura STAT_rec
ZAHTEV_REZ (TER->OR)
Polja u poruci: kod merenja (1)
IZVESTAJ_REZ (OR->TER)
Format poruke:
kod merenja
broj poslatih blokova
rezultati
1 1
Gde je:
kod merenja = identifikacioni bajt za odre|eno merenje iz intervala 0-(MAXMER-1)
broj poslatih blokova = broj blokova rezultata (3d matrica)
111
rezultati = niz 16-bitnih broja~a (od MAX_IZVOR*MAX_ODRED*MAX_PORUKA elemenata) koji predstavljaju 3D matricu rezultata ( uvek se {alje fiksan broj bajtova bez obzira na broj definisanih izvora,poruka i rezultata od strane korisnika)
IZVESTAJ_REZ_POT (TER->OR)
Polja u poruci: kod merenja (1)
BRISANJE_MER (TER->OR)
Polja u poruci: kod merenja (1)
BRISANJE_POT (OR->TER)
Polja u poruci: kod merenja (1)
