CAPITOLUL 7.

Software pentru sisteme de comutaie

Apariia sistemelor informaionale a permis realizarea sistemelor de comutaie pe baz de program nregistrat. Datorit avantajelor oferite, productorii de sisteme de comunicaie s-au orientat definitiv ctre aceast soluie care permite: - controlul centralizat asupra ntregului sistem; - schimbri funcionale i de configuraie ale sistemului prin folosirea unei proceduri simple care implic, n general, doar modificarea unor instruciuni din programul nregistrat; - adaptarea uoar a sistemului la servicii noi, introduse n reeaua de telecomunicaii. De-a lungul timpului, comanda cu program nregistrat a cunoscut o evoluie condiionat de stadiul de dezvoltare al tehnicilor i tehnologiilor ncorporate n realizarea sa practic, precum i de nivelul conceptual (de principiu) atins pe baza experienei anterioare. Astfel, iniial, introducerea comenzii cu program nregistrat a vizat doar nlocuirea logicii cablate a sistemelor electromecanice de comunicaie, restul componentelor rmnnd neschimbate. Odat cu apariia sistemelor electronice de comutaie, dorina de tipizare a orientat productorii ctre conceptul de program generic, identic pentru toate realizrile din aceeai generaie. Pe baza acestui program se executau toate operaiile legate de prelucrarea apelurilor, de identificarea i diagnosticarea deranjamentelor i de administrarea sistemului prin intermediul diverselor activiti ncorporate, de exemplu observarea traficului deservit de sistem. Cu toate c programul generic era acelai, situaia real n care funciona (configuraia reelei de acces, planul de adresare etc.) se deosebea de la un sistem de comunicaie la altul. Pentru a oferi flexibilitatea din acest punct de vedere, sistemele de comunicaie au fost dotate cu o baz de date n care se nscriau informaiile cu caracter particular precum: configuraia legturilor cu mediul

exterior (linii de abonat, jonciuni etc.), relaiile dintre componentele comandate, planul local de adresare. Programul generic a condus la mrirea corespunztoare a memoriei de nregistrare a programului. Deoarece, n general, o anumit aplicaie utilizeaz doar o parte din funciile oferite de programul generic, volumul necesar de memorare a devenit nejustificat de mare (din punct de vedere financiar i tehnic). Pentru a corecta aceast deficien, urmtoarea generaie de sisteme de comunicaie a fost nzestrat cu variante ale programului generic complet, care conin doar funciile cerute de situaiile concrete deservite.

7.1 Cerine n proiectarea software-ului de comutaie Proiectarea software-ului de comutaie este condiionat de un ansamblu complex de cerine de cele mai multe ori contradictorii. Aceste cerine in n principal de preteniile clienilor ce vor fi abonai la respectivul sistem i de obiective urmrite de viitorii proprietari i/sau administratori (operatori) ai acestuia. Criteriile principale dup care se orienteaz cei interesai n achiziionarea i exploatarea de sisteme de comunicaie sunt: satisfacerea cerinelor tehnice (capacitate, servicii disponibile,...) costul ciclului de via alctuit din trei componente: costul investiiei, costul dezvoltrii, costul ntreinerii i posibilitile oferite de mbuntire i introducere de noi servicii prin care se asigur creterea beneficiului. Pe baza acestor criterii, care sunt n majoritate de ordin financiar, se ia n final decizia asupra sistemului care trebuie s fie achiziionat. Relaia dintre costul investiiei i costul dezvoltrii reprezint un factor important de care trebuie s in cont att proiectantul ct i achizitorul unui sistem de comutaie. n acest sens, figura 7.1 prezint dou posibiliti de variaie n timp a costului de dezvoltare a dou sisteme de comutaie identice din punct de vedere

al performanelor tehnice. Comparnd cele dou variante se desprinde concluzia c dei prima variant (1) este mai ieftin din punct de vedere al costului iniial, cheltuielile ulterioare de dezvoltare dau ntietate celei din urm (2). Salturile mai mari n costurile de investiie apar la creterea capacitii peste anumite praguri, creteri ce impun aciuni cu pre mai ridicat (de exemplu produse de adugarea unui alt procesor). Pentru a oferi soluii atractive, proiectarea unui sistem de comutaie trebuie s urmreasc ca aceste limite s fie ct mai avansate, iar depirea lor s se fac cu investiii ct mai mici.

Figura 7.1 Comparaie ntre costurile de dezvoltare a dou sisteme de comutaie Costul ntreinerii este un alt factor important, care este urmrit de beneficiar i care trebuie avut n vedere n etapa de proiectare. El se reflect n activitile de operare, administrare i meninere a sistemului n stare de funcionare (mentenabilitatea sistemului). Pentru obinerea unor cheltuieli reduse de operare i administrare, furnizorul sistemului trebuie s ofere: - manuale clare i complete, care sunt absolut necesare instruirii personalului uman, - interfee om-main "prietenoase", cu o gam de mesaje adecvate i lipsite de ambiguitate,

- procedee de dezvoltare, care s implice ct mai puin operatorul att n modificrile de hardware ct i n cele de software. Pentru realizarea unor cheltuieli reduse de depanare sunt necesare metode simple i rapide de readucere n serviciu a componentelor intrate n avarie. n acest fel, precum i prin nzestrarea fiecrei componente hardware sau software cu toleran la defeciunile din jur, iar a sistemului cu posibiliti de reconfigurare, disponibilitatea este meninut n limitele acceptate de abonai. n ultim instan, amortizarea cheltuielilor ciclului de via i obinerea de beneficii depind de interesul clienilor de a utiliza un anume sistem de comutaie. Din acest motiv, proiectarea sistemelor de comutaie trebuie s urmreasc i satisfacerea preteniilor viitorilor abonai. Acetia doresc, n principal, uniformizarea modului de folosire a serviciilor indiferent de tipul comutatorului accesat, satisfacerea cererilor de serviciu la prima ncercare (disponibilitatea sistemului din punct de vedere al utilizatorului) i promptitudine n servire (de exemplu: recepionarea imediat a tonului de disc, satisfacerea apelului din prima ncercare etc.). Satisfacerea complet a utilizatorilor unui sistem de comutaie conduce n general la investiii nejustificat de mari. Acest impas este depit dac modul de funcionare al sistemelor de comutaie creeaz clienilor impresia c exigenele lor sunt respectate, c fiecare terminal are control complet asupra resurselor acestora. Atingerea acestui obiectiv, presupune reformularea cerinelor de care trebuie s in seama activitatea de proiectare: cerine de timp real i cerine de timp partajat.

7.2 Suportul software-ului de comutaie n orice tip de activitate, spiritul i materia se condiioneaz reciproc: spiritul organizeaz i controleaz materia, iar materia este cea care ofer suportul

existenei spiritului. n cazul software-ului de telecomunicaii (i nu numai), suportul este constituit dintr-un cod pentru a-l scrie, o memorie pentru a-l nmagazina i un procesor pentru a-l executa. De modul n care este conceput codul i este organizat memoria, precum i de viteza de execuie a instruciunilor (viteza procesorului) depinde n mare msur satisfacerea cerinelor amintite n capitolul anterior.

7.2.1 Viteza procesorului n general, procesoarele (microprocesoarele) execut un program ce este format prin nlnuirea mai multor instruciuni. Instruciunea este constituit dintro secven specific de operaii de baz, numite i cicluri-main, M, ca de exemplu: - ncrcarea (extragerea) codului operaiei (instruciunii); - citirea unui operand (dac operaia o cere); - executarea operaiei; - scrierea rezultatului (dac operaia o cere).

Figura 7.2 Structura general a unei instruciuni Z 80 Un ciclu-main format din mai multe perioade (cicluri) de ceas, T, (numite i stri) i poate fi prelungit la nevoie prin inserarea unor stri WAIT. Execuia

unei instruciuni (un ciclu-instruciune) va nsemna deci o succesiune de cteva cicluri-main, care presupun fiecare la rndul lui parcurgerea mai multor cicluri de ceas. Operaiile de citire i scriere vizeaz att memoria extern ct i dispozitivele de intrare / ieire cu care este echipat configuraia n care lucreaz microprocesorul. Figura 7.2 prezint structura general a unei instruciuni specifice microprocesoarelor Z 80. Aplicaia 7.1 In general, instruciunile unui procesor presupun mai multe cicluri main. Considernd c un microprocesor execut n rulare trei tipuri de instruciuni de 1, 2 i 4 cicluri main, care apar n programe cu probabilitile p(1) = 0,7; p(2) = 0,2 i respectiv p(4) = 0,1, s se determine durata medie a unei subrutine de 100 de instruciuni. Se precizeaz c durata ciclului main este de 1 sec. * * * Valoarea duratei ciclului main reprezint unul din principalii factori de care depinde viteza de execuie a programelor. n cazul sistemelor de comutaie, aceast dependen, care se face simit n numrul de apeluri ce pot fi prelucrate ntr-un anumit interval, i determin pe proiectani s se orienteze ctre utilizarea de procesoare rapide. Ele ofer n prezent durate ale ciclului main de ordinul zecimilor i sutimilor de sec. Aplicaia 7.2 S se determine valoarea maxim a numrul mediu de apeluri prelucrabile ntr-o or de un sistem de comutaie uniprocesor tiind c: - prelucrarea unui apel necesit execuia a 100 de instruciuni; - fiecare instruciune presupune executarea a 5 cicluri main; - un ciclu main dureaz 0,1 sec;

0,05% din ciclurile executate ntr-o or sunt rezervate activitilor de ntreinere. *** n realitate, serviciile oferite de un sistem de comutaie se difereniaz n raport cu numrul de cicluri main necesare fiecruia (de exemplu: aducerea unui apel n starea de convorbire poate implica 5000 de cicluri main n cazul unui post particular i 20.000 de cicluri main n cazul unui post public). Din acest motiv, stabilirea capacitii de prelucrare (BHCA - Busy Hour Call Attempt) a unui sistem de comutaie se face utiliznd diverse modele matematice sau programe de simulare. Aplicaia 7.3 S se determine valoarea maxim a numrului mediu de apeluri prelucrabile ntr-o or de un sistem de comutaie uniprocesor tiind c: - sunt 3 categorii de apeluri: de 1000, 2000 i 4000 de cicluri main; - apelurile aparinnd celor 3 categorii au probabilitile de apariie: p(1) = 0,7, p(2) = 0,2 i p(3) = 0,1; - un ciclu main dureaz 0,1 sec; - nu se rezerv timp pentru alte activiti. Indicaie de rezolvare: se va folosi media sumei unui numr aleator de variabile aleatorii sau distribuiile multinominale. * ** Aplicaia 7.4 Realizai un program care s simuleze situaia prezentat n aplicaia precedent. * * *

7.2.2 Organizarea memoriei Respectarea n ansamblu a cerinelor impuse unui sistem de comutaie face ca, din punct de vedere al organizrii memoriei, proiectarea s se orienteze ctre partajarea acesteia n dou componente: memoria fix i memoria variabil. n funcie de volumul celor dou componente i de raportul dintre ele, soluia aleas satisface anumite cheltuieli de investiie, ofer anumite performane .a.m.d. Memoria fix reprezint memoria minim necesar prelucrrii apelurilor de ctre un sistem de comutaie. Ea conine programul generic i pri din baza de date a sistemului de comutaie, precum i informaiile de rutare i de stare a apelurilor. Fiind absolut necesar, costul memoriei fixe se regsete evident n costul iniial al oricrui sistem de comutaie. Memoria variabil conine informaii referitoare la caracteristicile apelurilor generate de abonai (durate, rate de apelare, utilizare servicii suplimentare etc.) i ale echipamentelor ncorporate n sistem. Tendina de amplificare a memoriei variabile n orice situaie de dezvoltare a sistemului de comutaie, face ca ea s influeneze, prin costul su, cheltuielile generale de dezvoltare. n ultimii ani, costul memoriilor a sczut semnificativ. Cu toate acestea, obinerea unei capaciti minime de memorare rmne nc un obiectiv important al proiectrii, deoarece software-ul cu care sunt dotate sistemele actuale de comutaie a crescut substanial. Optimizarea memoriei se obine n general prin utilizarea larg a buclelor (do...while, for, ...) n cazul programrii i a compresiei informaiei n cazul bazelor de date. Aceste tehnici prezint ns i dezavantajul c structura programului i a bazei de date devine dificil de modificat n vederea includerii de noi caracteristici i tipuri de servicii.

7.2.3 Conceperea codului i programului Stabilirea instruciunilor, ce alctuiesc codul main, precum i

implementarea programului, pe baza cruia sunt ndeplinite activitile unitilor de comand din sistemele de comutaie, depind deopotriv de o serie de factori, dintre care cei mai importani sunt: - viteza procesorului utilizat, - capacitatea de memorare, - complexitatea programului, - constrngerile de timp real. Interdependena acestor factori este att de strns nct deciziile i soluiile propuse trebuie cntrite cu grij. Aplicaia 7.5 S se compare din punct de vedere al duratei i al memoriei alocate, dou variante de implementare a unui ciclu de explorare pentru 1000 de terminaii ale unui sistem de comutaie (tabelul 7.1). Terminaiile sunt repartizate n vederea explorrii n grupe de cte 8. Fiecare instruciune se desfoar pe durata unui ciclu main. Rezolvare: Conform coninutului (date i rezultate) din tabelul 7.1, prima variant este mai avantajoas din punctul de vedere al necesarului de memorie (utilizeaz de aproximativ 40 de ori mai puin memorie dect cealalt alternativ), dar cea de a doua variant este n schimb mai simpl i de trei ori mai rapid (sunt necesare doar 250 cicluri fa de 751).

Tabelul 7.1 Variante de realizare a programului de explorare

Adresa 1: Adresa 2: Varianta l fixeaz contor la 125; exploreaz rndul (contor); nregistreaz rezultatul explorrii; decrementeaz contor; testeaz contor; dac contor 0 salt la adresa 2; n caz contrar salt la adresa 1. Varianta II exploreaz rndul (1); nregistreaz rezultatul explorrii; exploreaz rndul (2); nregistreaz rezultatul explorrii; ............................................... exploreaz rndul (125); nregistreaz rezultatul explorrii.

Rezultate:
Numr de instruciuni Numr de cicluri 6 751 250 250

Observaie: exemplul, prezentat ca aplicaie, pune n eviden importana deosebit pe care o are faza de proiectare a programului. n aceast faz trebuie s se urmreasc stabilirea unei soluii optime, prin considerarea a dou obiective cu efecte contrarii: meninerea capacitii sub o limit acceptabil din punct de vedere economic i creterea numrului de activiti desfurate n timp real la valori suficient de mari, care garanteaz realizarea unor sisteme de comutaie performante. *** O alt cale de optimizare a software-ului const n definirea unor instruciuni i conceperea unor procesoare dedicate sistemelor de comutaie. n acest caz, pot fi ndeplinite activiti specifice, precum permutarea ciclic a 8 bii din interiorul unui cuvnt de 24 de bii (ntlnit n cadrul procesului de stabilire a cilor de comunicaie prin reeaua de conexiune), ntr-un numr de cicluri main mult redus fa de cazul utilizrii unui calculator de uz general. Tehnicile de optimizare a software-ului, descrise mai sus, au ca obiectiv obinerea unei soluii tehnico-economice avantajoase care s necesite un volum acceptabil de memorare i capaciti satisfctoare de procesare n timp real. Testarea soluiilor i ajustarea lor pn la forma final se realizeaz, n general,

prin simulri ce urmresc, n principal, stabilirea capacitii de prelucrare n timp real a variantelor analizate.

7.3 Software clasic de comutaie Un software de comutaie (i nu numai) este alctuit, n principal, din dou componente: programul i baza de date. Programul cuprinde toate instruciunile logice necesare ndeplinirii funciilor unui sistem de comutaie. Fiind proiectat pentru a funciona n orice context el se mai numete i program generic. Aceast flexibilitate este asigurat prin faptul c informaiile relative la echipamentele i utilizatorii specifici unui anumit sistem sunt nregistrate n baza de date proprie a acestuia.

7.3.1 Programul generic Programul generic ndeplinete o serie de funcii referitoare la: - prelucrarea apelurilor generate de abonaii proprii sau adresate lor, precum i a diferitelor servicii pe care sistemul l ofer abonailor, - ntreinerea sistemului - asigurarea i meninerea strii de funcionare a sistemului n ansamblu i pe componente, - administrarea sistemului - prin implicare n procesele de nnoire (updating) i observare (monitorizare) a sistemului respectiv. Din punct de vedere organizatoric, programul generic este alctuit dintr-un ansamblu de module program care ndeplinesc funcii specifice. Coordonarea activitii acestor module revine n sarcina unui program principal care le apeleaz conform unui anumit plan, n funcie de necesiti. Pentru a comunica ntre ele, modulele utilizeaz locaii de memorie comune i circuite tampon (buffer).

7.3.1.1 Prelucrarea apelurilor Sarcina principal pe care trebuie s o ndeplineasc un program generic const n stabilirea la cerere a unei ci de comunicaie ntre doi utilizatori. n cazul unui apel local, realizarea acestei sarcini presupune: 1. detectarea unei cereri de serviciu; 2. interpretarea informaiei de numerotare; 3. alertarea prii chemate; 4. stabilirea conexiunii propriu-zise; 5. taxarea; 6. eliberarea conexiunii.

Figura 7.3 Iniializarea programului pregtitor Cele ase activiti sus menionate reprezint funciile de baz utilizate n procesul de prelucrare a apelurilor, avnd n vedere c extensiile lor sunt utilizate i n satisfacerea celorlalte servicii oferite de sistemul de comutaie (apel distant, teleconferin, apel n ateptare etc.). Componenta software a funciilor de prelucrare a apelurilor este reprezentat de un ansamblu de programe care coordoneaz diverse activiti. Astfel, pentru detectarea cererilor de serviciu se utilizeaz programele de cutare care, periodic,

pe durata a aproximativ 100 msec exploreaz toate jonciunile (pentru depistarea eventualelor apeluri distante) i toate liniile de abonat (pentru depistarea eventualelor apeluri locale). n cazul liniilor de abonai, detectarea unui apel este urmat de nscrierea numrului terminalului corespunztor ntr-o locaie din memoria tampon a cererilor de servicii (figura 7.3). Memoria tampon a cererilor de servicii este trecut periodic n revist de ctre programul de control al execuiei care, dac detecteaz o nou cerere, activeaz un nou program pregtitor oferindu-i numrul terminalului corespunztor (aflat n stare de apel). Programul pregtitor are ca obiectiv conectarea terminalului la un receptor de cifre. Iniial, programul pregtitor creeaz o structur de date temporar, numit memorie terminal, care este completat prin copierea informaiilor necesare aflate n baza de date a sistemelor de comutaie (de exemplu: modalitatea de transmitere a informaiei de numerotare (impulsuri sau DTMF), identitatea terminaiei la care este conectat terminalul etc.). Baza de date conine nregistrri permanente ale abonailor, indexate dup numrul corespunztor al terminalului.

Figura 7.4 Organizarea unei nregistrri de apel n continuare, programul pregtitor activeaz o nregistrare de apel, care este o structur de date alctuit din trei seciuni, aa cum se prezint n figura 7.4, i anume:

1. seciunea "bloc de control" care conine informaii referitoare la: - starea (faza) curent a apelului, - temporizatoarele - supravegheaz expirarea unor intervale prestabilite de timp referitoare la anumite faze de prelucrare a apelului, cum sunt de exemplu recepia cifrelor de numerotare sau operaia de desfacere a conexiunilor la sfritul apelului, - viteza de explorare - variaz n funcie de faza de apel (de exemplu recepia cifrelor necesit o vitez de sondare mult mai mare dect detecia deconectrii), - adresele de legtur pentru o comunicaie cu alte nregistrri de apel sau cu alte blocuri de memorie (de exemplu cu memorii terminal). 2. seciunea "conexiuni fizice" - nmagazineaz informaii referitoare la identitile terminaiilor precum i ale conexiunilor stabilite n sistemul de comutaie pentru satisfacerea apelului n cauz. 3. seciunea "informaii interne speciale" abonailor implicai n apel, ct i informaia de taxare. reprezint o zon de lucru rezervat programelor generice. n plus, aceast seciune mai cuprinde att adresele

Figura 7.5 Conectarea receptorului de cifre n nregistrarea de apel selectat, programul pregtitor nscrie adresa de legtur la memoria terminal i identitatea echipamentului de linie corespunztor (figura 7.5). Urmeaz apoi gsirea unui receptor de cifre n repaus i unei ci de

legtur prin reeaua de conexiune ntre acesta i terminal. Cea din urm aciune se desfoar pe baza informaiilor de stare coninute n harta reelei. Harta reelei este o baz de date ale crei nregistrri conin informaii referitoare la strile de repaus (liber) sau de angajare (ocupat) ale traseelor (drumurilor) prin reea. Selectarea, respectiv eliberarea, unui traseu conduce la reactualizarea coninutului din harta reelei, adic la modificarea informaiei de stare referitoare la traseul respectiv (anume la toate elementele implicate n acest traseu). Un receptor de cifre reprezint o entitate cu o component hardware, care const dintr-o memorie tampon de numere, i o componenta software, constituit dintr-un program de decodificare a informaiei de numerotare recepionat n interfaa liniei de abonat. Angajarea sa de ctre un program pregtitor presupune ca cel din urm s memoreze datele asociate receptorului ntr-un segment de memorie temporar a crui adres de nceput (de legtur) o nscrie n nregistrarea de apel.

Figura 7.6 Structuri de date dublu nlnuite n procesul de achiziionare i prelucrare de date ce nsoete tratarea unui apel s-a optat pentru utilizarea de segmente de memorie temporare n dorina ca nregistrrile de apel s aib dimensiuni constante i ct mai mici. n acest fel restul

informaiilor, ce nu sunt necesare pentru toate funciile implicate n prelucrarea unui apel, sunt memorate separat, n segmente care n momentul n care nu mai sunt necesare sunt reintegrate n memoria neutilizat a sistemului. Pentru o comunicare rapid ntre diversele structuri de date ce corespund aceluiai apel, legturile dintre acestea sunt bidirecionale (figura 7.6). Prin conectarea receptorului de cifre la terminal, programul pregtitor i ncheie activitatea, programul de control al execuiei iniiind programul de decodificare a informaiei de numerotare. Pentru o corect recepie a cifrelor, ciclul de sondare al acestui program trebuie s fie rapid, n mod normal de 10 msec. Cifrele recepionate sunt colectate ntr-o seciune a memoriei tampon de numere, care este asociat nregistrrii de apel pe tot parcursul strii de numerotare (figura 7.7).

Figura 7.7 Activiti legate de recepia numrului Pe msur ce cifrele sunt nscrise n memoria numerelor, programul de control al execuiei activeaz programul de analiz al numrului care, n cazul unui numr valid, extrage din baza de date identitatea terminaiei de destinaie i informaiile de rutare pe care le depune n nregistrarea de apel. Cunoaterea identitii destinaiei d posibilitatea testrii strii acesteia. n cazul n care aceasta

este n repaus urmeaz cutarea a trei ci de comunicaie: una ntre terminaia "surs" i terminaia "destinaie", a doua ntre generatorul tonalitii de revers apel i terminaia surs i a treia ntre un generatorul curentului de sonerie i terminaia destinaie. Este evident c depistarea celei dinti dintre cele trei ci de comunicaie este decisiv pentru continuarea cutrii celorlalte dou. Dup gsirea cilor, marcate n harta reelei, programul de analiz a numrului se ncheie, iar programul de control al execuiei activeaz programul de avertizare. Acesta stabilete efectiv cile de avertizare (curent de sonerie i tonalitatea de revers apel) i iniiaz un program de supraveghere, ce urmrete detecia rspunsului la partea chemat sau deconectarea la partea chemtoare (figura 7.8).

Figura 7.8 Activiti legate de avertizarea abonailor La detectarea rspunsului, programele de sondare nscriu numrul terminalului chemat ntr-o memorie a rspunsurilor (figura 7.9). n continuare, programul de avertizare este dezactivat i sunt iniiate alte module program care stabilesc calea de convorbire ntre cele dou terminaii. ntruct apelul a intrat ntro stare relativ stabil, o bun parte din segmentele de memorie temporar sunt eliberate. Pentru sesizarea deconectrii, programele de sondare rmn active, iar atunci cnd acest eveniment se petrece, intervin programele de taxare i

deconectare, ce duc n final la trecerea terminaiilor n stare de repaus i la eliberarea nregistrrii de apel, ea devenind disponibil altor solicitri.

Figura 7.9 Activiti legate de rspunsul abonatului chemat 7.3.1.2 Funcii de ntreinere i administrare

Principala activitate a programului generic ine de prelucrarea apelurilor. Cu toate acestea, n majoritatea cazurilor, segmentul destinat acestei activiti reprezint doar 20% din totalul setului de instruciuni cuprinse n programul generic. Restul coninutului este destinat funciilor de ntreinere i administrare a sistemului de comutaie. Aceste funcii urmresc meninerea n limite prescrise a parametrilor de funcionare ai sistemelor de comutaie i realizeaz activitile urmtoare: - Depistarea i depanarea defectelor - funcii complementare ce au ca sarcin identificarea, semnalarea i analizarea situaiilor de avarie, cu scopul stabilirii cauzelor ce le-au determinat, precum i remedierea automat a defeciunilor n cazurile n care acest lucru este posibil. n cazul componentelor hardware, activitile amintite se materializeaz, de exemplu, n stabilirea unitii defecte i comutarea sistemului pe o unitate de rezerv, pus la dispoziie de redundana sistemului.

- Controlul suprasarcinilor - evalueaz gradul de ncrcare a sistemului de comutaie. Pe baza informaiilor oferite de aceast component a programului generic, funciile de prelucrare a apelurilor acioneaz n sensul meninerii stabilitii n funcionare a sistemului, chiar i n condiii severe de lucru, cnd volumul de prelucrri n timp real i traficul deservit ating valorile limit. - Verificrile curente - reprezint un ansamblu de programe destinate depanrii "din mers" a software-ului unui sistem de comutaie. n principal, ele se ocup cu recuperarea segmentelor pierdute de memorie, precum blocurile de memorie temporar i nregistrrile de apel disprute din evidenele listelor de structuri de date active sau n repaus i asistarea programelor de redresare a programelor de prelucrare apeluri ajunse n situaii neateptate. - Redresarea sistemului - funcia ce este activat atunci cnd o cauz major a afectat sistemul de ansamblu. Amploarea aciunilor ntreprinse de aceste funcii variaz de la caz la caz, nivelul maxim reprezentndu-l rencrcarea complet a programului generic. Pentru a evita aceast soluie extrem, n urma creia toate apelurile n curs de desfurare sunt ntrerupte, activitile de redresare a sistemului urmeaz o anumit ierarhie, n care cel mai sczut nivel de amploare este cel care are efecte negative minime pentru clienii sistemului. Astfel, de exemplu, redresarea sistemului poate debuta cu reiniializarea unui bloc de memorie care conine date invariabile. Dac aceast aciune nu a restabilit funcionarea sistemului, atunci funciile de redresare trec succesiv prin urmtoarele niveluri de amploare, pn ce activitatea de refacere d rezultatele dorite. Pentru a evita atingerea unor niveluri crescute de amploare, funciile de redresare ale sistemului colaboreaz cu restul funciilor de ntreinere. n acest fel, pe lng ajutorul oferit de cele din urm, funciile de redresare sistem primesc i o serie de indicatori utili pentru evaluarea gradului de degradare a sistemului i pentru stabilirea deciziei dac se trece sau nu la urmtorul nivel de amploare. Efectele generate de atingerea ultimului nivel de amploare pot fi limitate dac rencrcarea programului generic afecteaz doar apelurile aflate n faza

transmiterii. Acest lucru este posibil deoarece imaginea software a unui apel n stare de convorbire se limiteaz doar la o nregistrare de apei, iar detectarea sfritului de convorbire (deschiderea buclei la una dintre pri) se realizeaz prin programe de cutare identice cu cele n care terminaiile sunt n repaus. Funciile administrative ofer operatorului suportul desfurrii activitilor respective. Printre acestea se pot enumera: observarea traficului real, care este util ingineriei de trafic, modificarea informaiilor curente din locaiile bazei de date i inspectarea memoriei de lucru.

7.3.2 Organizarea bazei de date A doua component major a software-ului de comutaie o reprezint baza de date. Prin intermediul acestei componente, programul generic, proiectat n scopul deservirii unei arii largi de aplicaii, se integreaz ntr-un anumit context particular. Baza de date a unui sistem de comutaie conine informaii referitoare la utilizatorii i echipamentele acestora. a) Pentru fiecare utilizator, baza de date cuprinde, n principal: - numrul de telefon, - identitatea (adresa) terminaiei la care este conectat linia, serviciile la care are acces, - jonciunile utilizabile n cazul legturilor distante, - cile de rutare i informaiile de taxare. b) n privina echipamentelor, baza de date furnizeaz programului generic structura hardware a sistemului de comutaie. Descrierea structurii n cauz ia n considerare o serie de elemente precum: - numrul de cadre (repartitoare), - numrul de circuite din acestea,

- adresele prin care software-ul le poate accesa, - dimensiunea memoriei de lucru, - configuraia reelei de conexiune. Din punct de vedere organizatoric, baza de date se structureaz sub forma unei ierarhii de liste nlnuite. Prin adoptarea acestei soluii, se economisete memorie, o anumit informaie fiind nscris ntr-o unic locaie de memorie. Pentru a permite accesul la orice informaie din baza de date, fiecare nod al unei liste este o structur de date (practic, un tabel), care, pe lng diverse informaii, conine i adresele de legtur (pointer-i) la structurile de date subordonate (figura 7.10).

Figura 7.10 Liste nlnuite de structuri de date Vrful ierarhiei este ocupat de o structur master (structur primordial) care este nmagazinat ntr-o locaie fix a memoriei. Pentru restul structurilor ce sunt accesate, pornind de la adresele cuprinse n structura master, localizarea lor n memorie nu este unic, ele putnd fi transferate n funcie de necesiti (de exemplu: modificarea numrului de cmpuri cuprinse ntr-o structur de date) prin realocare de memorie. Pentru a se pstra integritatea listei, adresa de legtur coninut n structura de date superioar trebuie reactualizat.

Cutarea unei informaii nregistrat n baza de date se face parcurgnd listele de sus n jos. Pentru aceasta, programul generic acceseaz structura master, ca s extrag de aici, pe baza unui anumit criteriu, adresa urmtoarei structuri. De exemplu, figura 7,11 prezint schematic modul de organizare a unui segment din baza de date, care ofer identitatea terminaiei corespunztoare numrului abonatului chemat. Astfel, pe baza primelor 4 cifre din numr, se extrage din primul tabel adresa tabelului urmtor din care, pe baza restului de cifre, se extrage identitatea terminaiei cutate. Reprezentarea tabelelor subtranslatoare din figura 7.11 are un caracter pur didactic; n realitate, tabelele au o singur coloan, sufixul dup care se face cutarea constituind adres de indexare.

Figura 7.11 Identificarea terminaiei abonatului chemat

7.3.3 Software de comutaie telefonic Software-ul utilizat n prezent n majoritatea sistemelor de comutaie este rezultatul unui efort constant de cretere a eficienei care a urmrit prelucrarea a ct mai multe apeluri ntr-un timp ct mai scurt, utiliznd ct mai puine resurse. Parametrul major care condiioneaz aceast problem de optimizare l constituie legtura dintre capacitatea i costul sistemului. Variantele timpuri de software de comutaie au fost proiectate pentru a satisface n principal centralele telefonice care ofereau un numr restrns de

servicii. Odat cu dezvoltarea de noi servicii, software-ul s-a modernizat urmnd, ns, n general, aceleai principii. 7.3.3.1 Arhitectura software Arhitectura unui software curent de comutaie poate fi reprezentat ca n figura 7.12. Activitile unui sistem de comutaie sunt iniiate, n principal, de evenimentele ce survin la terminaiile de intrare ale acestuia. Sesizarea acestor este n sarcina programelor de intrare care, pentru corecta lor interpretare (a cifrelor, a ridicrii / coborrii furcii etc.), lucreaz n timp real (10 msec sau 100 msec pe ciclu). Reciproc, programele de ieire sunt destinate celuilalt sens de comunicare: de la sistemul de comutaie ctre ieirile acestuia (tot terminaii). Tampoanele de intrare/ieire au rolul de a intermedia schimbul de date ntre medii software ce lucreaz la viteze diferite (viteza de lucru a procesoarelor ce execut programele de intrare/ieire este, de obicei, mai mic dect a procesoarelor dedicate programelor interne).

Figura 7.12 Reprezentarea conceptual a arhitecturii software-ului de comutaie

Figura 7.13 Planul de nlnuire a programelor

Din punct de vedere al limbajului de programare, software-ul de comutaie utilizeaz conceptele de clas, funcii membre, obiecte motenire etc. (vezi limbajul C++). n acest sens, pentru o anumit activitate (de exemplu: analiza numrului) se definete o clas specificndu-se variabilele de lucru folosite i funciile implicate. Pe baza acestor clase, ori de cte ori trebuie iniiat o activitate se creeaz (instaniaz) un obiect care are acces la toate funciile clasei printe, doar variabilele personale de lucru ocupnd o locaie de memorie distinct. Astfel, desfurarea simultan a mai multor activiti de aceeai natur implic doar multiplicarea locaiilor de memorie necesare variabilelor de lucru, funciile membre rmnnd unicat. Atunci cnd un obiect i nceteaz existena, locaia de memorie aferent este disponibilizat (eliberat) pentru alte utilizri. Pentru a putea controla echipamentul hardware asociat activitilor sale, un obiect are control direct asupra interfeelor cu sistemul de comutaie prin intermediul funciilor membre ale clasei. Tot prin intermediul funciilor membre, un obiect are acces la memoria comun temporar i la nregistrrile de apel i poate nscrie direct date n tampoanele de ieire. 7.3.3.2 nlnuirea programelor nlnuirea programelor tip modul din cadrul unui software de comutaie urmeaz o anumit disciplin bazat pe conceptele de nivel de prioritate i nivel de ntrerupere. Toate modulele cuprinse n programul generic sunt caracterizate printr-un anumit nivel de prioritate. Pe baza acestui atribut, programele se clasific n categorii prefereniale. Numrul categoriilor prefereniale difer de la o aplicaie la alta. Figura 7.13 prezint un exemplu de plan de nlnuire a programelor difereniate n 5 categorii: A, B, C, D i E. Categoria A are nivelul de prioritate cel mai nalt, iar E are nivelul cel mai sczut, n momentul cnd mai multe programe cer a fi executate, programul principal l activeaz pe cel cu cea mai mare prioritate. Adoptnd

aceast politic, programele cu prioritate superioar (de exemplu programe de analiz a numrului) vor rula mai frecvent dect cefe cu prioritate inferioar (de exemplu programe de conectare la un generator de tonaliti), ceea ce este i de dorit. n numeroase situaii este necesar execuia unor programe ce nu sufer amnare. Aceste programe, numite ntreruperi, opresc temporar execuia programului curent, i desfoar activitile dup care repun n activitate programul sistat din locul n care s-a oprit. n general, aceste intervenii, nu perturb desfurarea programelor ntrerupte dect prin introducerea unor ntrzieri suplimentare n execuia lor. Totui, atunci cnd situaia o cere, intervenia unei ntreruperi poate duce chiar la abandonarea programelor n curs de desfurare. Activitile desfurate de ntreruperi se difereniaz prin importana lor. Din acest motiv este necesar ca i ntreruperile s prezinte diverse grade de prioritate. n acest fel, se evit ca o ntrerupere inferioar s ntrzie sau s sisteze temporar o ntrerupere de importan vital. n figura 7.13 se prezint modul de clasificare a ntreruperilor de ntreinere (A, B, C, D, E, F, G) i a ntreruperilor periodice (H i J). ntreruperile de nivel A sunt sub controlul operatorului uman, fiind destinate interveniilor de depanare sub supravegherea acestuia. Nivelul B este compus din aciunile de urgen prin intermediul crora, n mod automat, se analizeaz i se ncearc s se restabileasc buna funcionare a sistemului ajuns ntr-o faz critic. Celelalte niveluri, C - G, sunt destinate aciunilor de corectare a diverselor disfuncionaliti hardware de mai mic amploare. Nivelurile H i J cuprind activiti ce trebuie desfurate la momente precise. Aceste ntreruperi se ocup cu procesele de intrare/ieire (de exemplu: programele de cutare) i sunt coordonate de impulsurile generate de baza de timp (T= 5 msec) a sistemului.

7.3.3.3 Deficienele software-ului de comutaie telefonic Adoptarea principiilor de proiectare prezentate mai sus conduce la un software de comutaie fragmentat n module program, a cror funcionare se nlnuie temporar conform evoluiei unui apel telefonic (figura 7.14). Aceste module program trebuie s dein informaii detaliate relative la comportarea procesului n fazele luate n considerare (de exemplu: programul pregtitor trebuie s cunoasc tipurile de semnalizri ce le poate recepiona, temporizrile relative la ridicarea / coborrea furcii etc.) i la hardware-ul pe care-l are la dispoziie. Soluia asamblrii unui software de comutaie din astfel de module program conduce, n general, la programe de dimensiuni considerabile. Din acest motiv, proiectarea este nsoit de o susinut activitate de optimizare a codului, n vederea obinerii unei ocupri acceptabile de memorie i a unei operri eficiente. ns acest obiectiv este atins printr-o puternic specializare a modulelor program, acestea oferind pe ansamblul sistemului o prelucrare eficient a serviciilor pentru care au fost proiectate. Creterea eficienei de prelucrare este pltit prin ngreunarea procesului de dezvoltare a software-ului de comutaie n vederea introducerii unor noi servicii.

Figura 7.14 Efectul introducerii unul nou serviciu

Figura 7.14 prezint implicaiile produse de introducerea unui nou serviciu (apel n ateptare sau teleconferin) asupra structurii unui program modular pentru prelucrarea apelurilor. Includerea unui nou modul program, care este dedicat unui serviciu nou, implic modificri ale modulelor program din amonte (de exemplu programul pregtitor, ...) i de pe acelai nivel (programul de avertizare linie abonat,...); aceste modificri au scopul armonizrii n funcionare a ansamblului existent cu noul modul. n plus, modulul program destinat noului serviciu trebuie s cunoasc modul de funcionare a modulelor aflate pe acelai nivel sau n aval. Toate modificrile sus menionate conduc la creterea conectivitii, adic a interdependenei dintre modulele program. Acest lucru face ca schimbarea caracteristicilor unui anumit serviciu s necesite revizuiri n mai multe module program. O asemenea activitate complex de schimbare favorizeaz apariia unor disfuncionaliti, motiv pentru care orice modificare trebuie s fie nsoit de testarea amnunit a integritii ntregului sistem. Tendinele actuale i previziunile legate de dezvoltarea serviciilor pun n eviden creterea numrului i complexitii acestora (transmisii de date, imagini video, calcul cooperant, teleasisten medical etc.). Pentru a evita activitile dificile i costisitoare de integrare a noilor cerine n cadrul unor arhitecturi software de genul celei analizate, proiectanii i realizatorii de sisteme numerice de comutaie au dezvoltat un nou model de software de comutaie ale crui principale coordonate sunt prezentate n continuare.

7.4 Software-ul modern de comutaie Ritmul alert, de diversificare a serviciilor i de modificare a caracteristicilor acestora, a orientat activitatea de proiectare a software-ului de comutaie ctre identificarea unor soluii care s ofere flexibilitate ct mai mare la aceste

schimbri. Aceast flexibilitate trebuie s considere att serviciile viitoare, puse la dispoziie abonailor, ct i cerinele ulterioare pe care deintorii sistemelor de comutaie le vor manifesta n dorina unei operri, ntreineri i administrri superioare a acestora i, nu n ultimul rnd, s urmreasc ndeplinirea tuturor acestora n condiii tehnico-financiare i de eficien convenabile. Cutarea unei arhitecturi "ideale", care s ofere un grad nalt de flexibilitate, ia n considerare un ansamblu complex i dinamic de factori dintre care cei mai importani sunt urmtorii: mediul de procesare (n general, varianta distribuit primeaz asupra celei centralizate), dependena de tipul serviciului a echipamentului hardware i a structurilor de date (se urmrete a fi eliminat aceast dependen), gradul de modularizare (cu ct este mai accentuat, cu att mai uoar att definirea pentru fiecare tip de modul a unei interfee simple de testare ct i suplmentarea serviciilor; preul modularizrii excesive l constituie ns degradarea eficienei sistemului), interdependena dintre servicii (trebuie minimizat). Astfel de probleme cu grad nalt de dificultate se pot rezolva adoptnd metodologiile elaborate n cadrul domeniului de cercetare cunoscut ca ingineria software. n cazul aplicaiilor de uz general, acest cadru de lucru i-a demonstrat calitile oferind software de nalt calitate n condiii de cretere a productivitii. Utilizate i n cazul sistemelor de comutaie, metodologiile ingineriei software trebuie completate cu tehnici de optimizare, care s corecteze rezultatele iniiale, ineficienta din punct de vedere al timpului de execuie i al volumului de memorie utilizat, n vederea obinerii unei soluiei finale, care s rspund tuturor cerinelor impuse unui software de comutaie.

7.4.1 Elemente de inginerie software Ingineria software s-a dezvoltat ca urmare a necesitii de a crea un cadru organizat de concepere a software-ului care s asigure produse de calitate n condiii superioare de productivitate. Aa cum se precizeaz i n figura 7.15, ingineria software a redus substanial efortul de dezvoltare (-50%) i de ntreinerea (~75%) fa de procedeele premergtoare.

Figura 7.15 Beneficiile ingineriei software fa de experiena anterioar Aceste rezultate s-au obinut prin perfecionare continu i aplicare susinut a trei categorii de concepte, ce sunt prezentate n continuare: 7.4.1.1 Structura software-ului Experiena acumulat de-a lungul timpului a artat c modul de concepere are o influen major asupra caracteristicilor unui software de comutaie. Astfel, flexibilitatea atinge cote presupune fracionarea software-ului n funcii componente de mic ntindere, a cror activitate comun se bazeaz pe legturi minime de interdependen. Funciile de mic ntindere, sub 100 de instruciuni,

sunt avantajoase deoarece ele sunt uor de scris, de corectat, de verificat sau de modificat. De exemplu, pentru sondarea strii unei linii se poate crea o funcie care returneaz o variabil booleana (DA / NU) ce semnaleaz "nchiderea" sau "deschiderea" buclei. Aceast funcie poate fi activat de o alt funcie (printe) care se ocup cu identificarea buclelor nchise. n acest caz, interfaa dintre cele dou funcii este constituit de schimbul de informaii dintre acestea: ntr-un sens, argumentul furnizat funciei copil de ctre funcia printe (este vorba de identitatea liniei), iar n cellalt sens, valoarea ntoars (returnat) de ctre funcia copil spre funcia printe. Un alt concept important legat de structura software-ului l constituie capacitatea programului de a face abstracie de modul de reprezentare a informaiei n bazele de date aferente. Dispunnd de aceast nsuire, un software de comutaie i micoreaz sensibilitatea la modificrile ulterioare ce vor afecta structurile bazelor de date cu care intr n contact. O soluie care asigur abstractizarea sus menionat o constituie intercalarea ntre program i structura de date a unui subsistem de administrare a bazei de date. Prin intermediul acestei componente, funciile au acces la informaii, fr s le mai fie necesar cunoaterea modului n care acestea sunt reprezentate n baza de date curent. 7.4.1.2 Metodologia de dezvoltare Un factor important care influeneaz decisiv calitatea software-ului l constituie metodologia de dezvoltare a acestuia. Aceast metodologie se refer, n principal, la tehnicile propriu-zise de programare-dezvoltare i la modul de organizare a echipei de proiectare. De-a lungul evoluiei generale a sistemelor informaionale, dar i a evoluiei particulare a sistemelor de comutaie cu program nregistrat, s-au experimentat diverse tehnici de programare-dezvoltare de software. Elaborate iniial n mod

empiric, aceste tehnici au urmat un proces evolutiv n care dorina fundamentrii teoretice a condus ctre soluii tot mai performante, att din punct de vedere al calitii software-ului, ct i al timpului alocat dezvoltrii sale. n prezent, printre tehnicile de dezvoltare aplicate cu succes se numr i cea a dezvoltrii de sus n jos. Realizarea unui ansamblu software ierarhizat bazat pe aceast tehnic presupune c dezvoltarea sa ncepe din vrful ierarhiei i continu cu abordarea succesiv a nodurilor din nivelurile ierarhice inferioare. Din punct de vedere software, fiecare nod al ierarhiei reprezint o funcie (un modul program) care, nainte de a fi integrat n ansamblu, trebuie s fie temeinic verificat. Astfel, n cazul adoptrii n proiectarea software-ului a principiului diviziunii funcionale, funciile printe sunt testate naintea funciilor subordonate. n privina modului de organizare a echipei de proiectare, acesta a progresat continuu pe baza experienei i a studiilor ntreprinse n aceast direcie. Un astfel de studiu ntreprins de IBM a demonstrat, de exemplu, eficacitatea organizrii de tipul echip cu programator ef. O astfel de echip este alctuit din specialiti n diverse domenii software, selectai n funcie de obiectivul urmrit. Dintre ei se desemneaz programatorul ef, lui revenindu-i sarcina de a coordona activitatea echipei subordonate. 7.4.1.3 Mijloace de dezvoltare Creterea continu a complexitii activitilor legate de definirea funciilor i de transpunerea lor n plan software a fcut necesar dezvoltarea unor mijloace (unelte = tools), care s ofere un suport de desfurare eficient a acestora. "Uneltele" cele mai folosite n ingineria software-ului de comutaie sunt: limbajul de specificare i descriere, diagrama de secvene ale mesajelor, limbajele de nivel nalt.

A. Limbajul de specificare i descriere, SDL n 1976, CCITT a pus la dispoziia proiectanilor de software pentru comutaie un limbaj (formal) de specificare i descriere, SDL, (Specification and Description Language). Acest "limbaj" este recomandat att pentru specificarea funcionalitii unui sistem de comutaie ("ce are de fcut"), ct i pentru descrierea detaliat, la nivel logic, a funciilor propriu-zise ("cum se face"). Prelund diferite concepte i metode dezvoltate n cadrul teoriei automatelor cu stri finite, limbajul SDL permite descrierea de structuri i procese prin intermediul unor cuvinte cheie i/sau a unor simboluri grafice.

Figura 7.16 Concepte SDL pentru reprezentare grafic a structurii unui sistem 1. Astfel, pentru prezentarea structurii unui sistem, limbajul ofer conceptele de sistem, bloc i canal a cror reprezentare grafic, SDL/GR (Graphic Representation), este coninut n figura 7.16. n dorina de a oferi mai multe niveluri de detaliere, blocurile pot fi descompuse, la rndul lor, n sub-blocuri i canale. Pentru aceast operaiune, limbajul SDL pune la dispoziie dou noiuni specifice: - sub-structur - pentru a specifica modul de alctuire a unui bloc cu structur intern, - despicare - pentru a descrie modul n care un canal legat la bloc se despic n interiorul acestuia n mai multe canale. 2. Limbajul SDL permite i descrierea sub form de text, SDL/PR, (Phrase Representation) a structurii unui sistem. Cteva forme de sintax pot fi folosite:

a) pentru definirea unui sistem: SYSTEM [nume]; [definiii semnale] [definiii canale] [definiii blocuri] ENDSYSTEM [nume]; b) pentru definirea unui bloc: BLOCK [nume]; [definiie proces] [definiie sub-structur] ENDBLOCK [nume]; c) pentru definirea unui canal: CHANNEL [nume] FROM [nume bloc/ENV] TO [nume bloc/ENV] WITH [list semnale]; [ENV specific legtura cu exteriorul sistemului; environment] d) pentru definirea unei despicri: SPLIT [nume canal despicat] INTO [list canale]; e) pentru declararea de sub-blocuri: SBBLOCKS [list cu numele blocurilor incluse]; f) pentru declararea canalelor dintr-o anumit structur: CHANNEL [list cu numele/identitatea canalului]; g) pentru definirea unei sub-structuri: SUBSTRUCTURE [numele blocului a crui structur este descris]; [declarare sub-blocuri coninute] [declarare canale coninute] [definirea despicrilor] [definirea blocurilor] [definirea canalelor] END SUBSTRCTURE [numele blocului a crui structur a fost descris];

h) pentru declararea semnalelor: SIGNAL [list semnale] Observaie: declararea unui semnal se rezum la nume sau poate include i tipurile de date transportate. Conform listei de mai sus, instruciunile prin care se reprezint structura unui sistem se mpart n dou categorii: definiii - reprezint o descriere complet a entitilor (sistem, bloc,.....) asupra crora se rsfrng, declaraii - reprezint doar o enumerare a acestor entiti. Dei par a fi redundante, declaraiile i gsesc aplicare n numeroase situaii, i anume atunci cnd introducerea unor entiti (blocuri, canale,...), n descrierea SDL textual, precede definirea acestora. Aplicaia 7.6 S se prezinte n limbaj SDL/PR sistemul descris prin intermediul limbajului SDL/GR n figura 7.17. Notaiile ncadrate n paranteze drepte reprezint denumirile semnalelor transmise pe canalele corespunztoare.

Figura 7.17 Sistem definit cu ajutorul limbajului SDL Rezolvare: SYSTEM A; SIGNAL S1.S21.S22; CHANNEL C1 FROM B1 TO B2 WITH S1; CHANNEL C3 FROM B2 TO B3 WITH S21, S22; BLOCK B1

. . . ENDBLOCKB1; BLOCK B3; . . . BLOCK B2; SUBSTRUCTURE B2; SUBBLOCKB21.B22; CHANNEL C11, C12, C21, C22; SPLIT C1 INTO C11, C12; SPLIT C3 INTO C21, C22; BLOCK B21; . . . ENDBLOCK B21; BLOCK B22; . . . ENDBLOCK B22; CHANNEL C11 FROM ENV TO B21 WITH S1; CHANNEL C12 FROM ENV TO B22 WITH S1; CHANNEL C21 FROM B21 TO ENV WITH S21; CHANNEL C22 FROM B22 TO ENV WITH S22; ENDSUBSTRCTURE B2; ENDBLOCK B2; ENDSYSTEM A; *** Descrierea complet a unui sistem presupune prezentarea att a structurii ct i a modului de funcionare a componentelor sale. n cazul limbajului SDL, pentru definirea unitilor funcionale (dinamice) se utilizeaz conceptul de proces.

Un proces reprezint un automat extins cu numr finit de stri (Anexa 4), care este ataat unui bloc fr structur intern. Un bloc poate dispune de mai multe procese. Aceast flexibilitate a gruprii proceselor (unul sau mai multe n acelai bloc) este oferit pentru a satisface diversele necesiti de proiectare. Procesele se pot grupa n blocuri ce asigur aceleai activiti, realizndu-se astfel minimizarea numrului lor. O aciune n sens opus, anume segmentarea pe mai multe blocuri, permite o implementare eficient a proceselor complexe.

Figura 7.18 Exemplu de reprezentare grafic a componenei la nivel de proces Apartenena proceselor la blocuri se reprezint ca n cazul particular precizat n figura 7.18. n funcie de necesiti, fiecare proces se poate descompune n servicii, care reprezint i ele tot nite automate extinse cu stri finite. Dar spre deosebire de procese, care se preteaz unei execuii paralele, serviciile aparinnd aceluiai proces nu au aceast libertate, deoarece unul singur dintre acestea se poate afla, la un moment dat, n execuie. Deseori, pe parcursul descrierii unui proces pot aprea pri identice, n acest caz, pentru a simplifica modul de descriere a procesului, aceste pri comune pot fi incluse ntr-o procedur definit o singur dat. Reprezentarea grafic a unei organizri n servicii i proceduri a unei structuri ipotetice este oferit n figura 7.19.

Figura 7.19 Exemplu de reprezentare grafic a componenei la nivel de proces Un proces (sau serviciu) este alctuit din stri i tranziii ntre stri. O stare reprezint o anumit situaie n care procesul este suspendat n ateptarea unui semnal de intrare (stimul). Un semnal este o secven de informaii destinat unui proces. Semnalele pot fi de origine hardware sau software. Semnalele pot fi externe, cnd comunicaia are loc ntre procese localizate n blocuri distincte, sau interne n caz contrar.

Figura 7.20 Exemplu de utilizare a rutelor cuprinse ntr-un bloc Cile de comunicaie din interiorul unui bloc se numesc rute. Aceste rute leag procesele la alte procese sau la canalele conectate la blocul corespunztor

(figura 7.20). Dac, de exemplu, procesul P31 este descompus n dou servicii, atunci structura sa intern se reprezint ca n figura 7.21.

Figura 7.21 Exemplificarea rutelor n interiorul unui proces compus din servicii Tranziia este o succesiune de aciuni care nsoete trecerea unui proces dintr-o stare ntr-alta, ca rspuns la o intrare (stimul) anumit. De exemplu, un proces de prelucrare apeluri aflat n starea LIBER va tranzita n starea NUMEROTARE, activnd un generator de ton (prin trimiterea unui semnal de ieire), i se va pregti pentru recepia cifrelor, atunci cnd va fi stimulat de semnalul de ANGAJARE (corespunztor acionrii furcii de comutaie la deschiderea aparatului chemtor). Principalele simboluri utilizate n descrierile grafice ale procesoarelor sunt prezentate n figura 7.22 [GEODE 93]. Semnificaiile unora dintre acestea au fost deja precizate, rmnnd ca n continuare s fie explicate i celelalte: DECISION: - definete mai multe variante ce pot fi urmate pe parcursul unei tranziii funcie de rspunsul obinut n urma verificrii unor condiii. TASK: - definesc orice activiti care se desfoar pe parcursul unei tranziii ce nu este nici decizie, nici ieire. SAVE: - ofer o metod de punere n rezerv a unui semnal, cnd procesul se afl ntr-o anumit stare. n acest fel, se poate amna prelucrarea semnalului pn se ndeplinesc i alte condiii

CONNECTOR: - este o etichet unic util n cazul n care un proces este descris pe mai multe pagini. PROCEDURE CALL: - orienteaz parcurgerea descrierii ctre o procedur precizat n apel. RETURN: - revenirea n punctul de unde procedura a fost iniiat. CREATE REQUEST: - creeaz o nou instan a procesului precizat n apel. STOP: - ncheie existena instanei corespunztoare.

Figura 7.22 Principalele simboluri SDL Aplicaia 7.7 Analizai diagrama simplificat de tranziii i stri din figura 7.23 ce descrie un proces de tratare a unui apel local (pentru detalii se recomand a fi consultate avizele CCITT Z.101 - Z.103, precum i figura 1 ce le este anexat). Precizai ce sunt T0, T1, T4 i la ce se utilizeaz acestea? * * *

Figura 7.23 Tratarea unui apel local - plana 1/2

Figura 7.23 "Tratarea unui apel local (continuare) - plana 2/2

B. Diagrama de secvene ale mesajelor, MSC Descrierea funcionrii unui sistem se poate realiza i prin intermediul diagramelor de secvene ale mesajelor, MSC (Message Sequence Charf). O diagram MSC conine schimburile de mesaje ntre diversele componente structurale ale unui sistem. Pentru asigurarea compatibilitii ntre cele dou limbaje, componentele luate n considerare n cadrul diagramelor MSC trebuie descrise la nivel static (structur, ci de comunicaii, semnale,...) sub form SDL.

Figura 7.24 Exemplu de diagram MSC O diagram MSC se prezint sub forma: exemplului din figura 7.24. Conform acesteia, liniile verticale corespund diverselor componente (instane) ale modelului (sistem, bloc, proces, mediu), iar liniile orizontale (eventual oblice) corespund evenimentelor legate de comunicarea ntre componentele modelului (semnalul emis sau recepionat, ruta sau canalul utilizat) sau de iniierea/expirarea unor temporizatoare. Modul de ordonare pe vertical a liniilor orizontale trebuie s respecte cronologia evenimentelor luate n considerare. Principalele simboluri utilizate n reprezentrile MSC compatibile SDL sunt prezentate n figura 7.25.

Figura 7.25 Principalele simboluri ale reprezentrilor MSC Aplicaia 7.8 S se traseze n diagrame MSC evoluia unui apel telefonic local, descris anterior cu diagrama SDL din figura 7.23. Blocurile funcionale luate n considerare sunt reprezentate n figura 7.26. Se vor analiza scenariile urmtoare: i) apelul este satisfcut i sfritul su este comandat de ctre abonatul A; ii) apelul nu este satisfcut deoarece abonatul B este ocupat; iii) apelul este abandonat dup formarea a dou cifre; iv) abonatul B nu rspunde, iar abonatul A ateapt pn se epuizeaz temporizatorul T4.

Figura 7.26 Interaciunea dintre blocurile implicate n tratarea unui apel local Indicaie: pentru cazul apelului satisfcut diagrama MSC este precizat n figura 7.27.

Figura 7.27 Interaciunea dintre blocurile implicate n tratarea unui apel local ***

C. Limbaje de nivel nalt Tot din categoria mijloacelor de dezvoltare a software-ului fac parte i limbajele de nivel nalt. Aceste limbaje au fost concepute i perfecionate pentru a oferi un cadru mult mai eficient de programare n comparaie cu limbajele de asamblare (productivitatea programrii n limbaje de nivel nalt este cu cteva ordine de mrime mai mare dect n cazul limbajelor de asamblare). Faptul c, iniial, software-ul de comutaie era scris n limbaj de asamblare, se datora necesitii de a face economie de memorie i de timp real de execuie. Ulterior ns, o serie de factori au orientat definitiv proiectarea de software ctre utilizarea limbajelor de nivel nalt (CHILL, C++). Astfel, scderea preului la memoriile semiconductoare a eliminat restriciile severe legate de dimensiunea memoriei, iar nzestrarea compilatoarelor cu posibiliti de optimizare a codului generat a permis obinerea de programe cu un nivel de eficien acceptabil. Ingineria software presupune un ansamblu complex de activiti. Pentru a se putea desfura n condiii optime, activitile de rutin care nu in de conceperea, dezvoltarea i verificarea unui produs software s-au automatizat fiind ndeplinite de software-uri specializate, cum sunt: - biblioteca de programe (support library) - nmagazineaz documentele ce aparin la diverse proiecte de dezvoltare software. Prin documente se neleg att codurile main ct i fiierele surs. - administratorul bibliotecii de programe (program librarian) - este interfaa dintre echipa de proiectare i biblioteca de programe. n aceast ipostaz, administratorul nfptuiete o serie de funcii precum: meninerea integritii bibliotecii astfel nct coduri aflate n faza de dezvoltare s nu se suprapun accidental peste produse finalizate; nlesnirea controlrii planului de dezvoltare a produselor software; asigurarea revenirii la etape anterioare de proiectare, n prezent, ingineria software dispune de mijloace deosebit de performante care integreaz mijloacele de dezvoltare prezentate mai sus. n acest fel, proiectarea se realizeaz utiliznd, de exemplu, limbaj SDL, iar trecerea n cod

surs i generarea de cod main revin n exclusivitate mediului integrat de lucru [OPNET 90], [GEODE 93].

7.4.2 Procesarea distribuit Mediul de procesare reprezint un alt factor important ce caracterizeaz o anumit arhitectur software. Funcie de numrul de procesoare implicate i de modul de lucru al acestora, procesarea se poate desfura serial sau paralel. Procesarea serial presupune c la un moment dat un singur procesor se afl n execuie, iar procesarea paralel se ntlnete n configuraiile n care mai multe procesoare funcioneaz simultan desfurnd activiti n comun. Iniial, software-ul de comutaie a utilizat un mediu de procesare serial. Odat cu creterea volumului de activiti, viteza de execuie a procesoarelor a devenit ns insuficient. Ca urmare, o soluie a fost creterea vitezei de execuie care, ns, implic costuri superioare de fabricaie i, n plus, este limitat din punct de vedere fizic. Pentru a depi aceste piedici, s-a trecut la producerea de software-uri de comutaie ce lucreaz n mediu de procesare paralel. Aceast soluie ofer rezultate superioare, mai ales atunci cnd se adopt principiul diviziunii funcionale a proceselor software. Aceast diviziune, ce asigur operarea unui sistem ntr-un mediu distribuit, trebuie ns corelat cu o minimizare a comunicaiilor (interdependen redus). Altfel, este posibil ca un sistem distribuit s funcioneze sub capacitatea unui sistem echivalent cu procesare serial.

7.4.3 Model optim de arhitectur software Cercetrile efectuate n vederea realizrii unui model optim de arhitectur software trebuie s in seama de ansamblul conceptelor ce au fost prezentate pe parcursul acestui capitol, n principal, aceste concepte se refer la: procesarea paralel (distribuit), sisteme distribuite, diviziune funcional, interdependen redus, ingineria software, abstractizarea informaiei.

Att baza de plecare, prin complexitatea sa, ct i cerinele impuse, prin diversitatea lor, conduc la obinerea mai multor soluii n problema identificrii unei arhitecturi software ideale. Una dintre aceste soluii este prezentat n continuare, la modul principial. 7.4.3.1 n figura 7.28. Structura modelului

Un model ideal de arhitectur software pentru comutaie se poate prezenta ca

Figura 7.28 Exemplu de arhitectur software de comutaie

n acest caz, structura conine cinci procesoare specializate pe diverse funcii. Procesoarele i ndeplinesc funciile n urma stimulrii reciproce, fr ns ca aciunile implicate de o anumit funcie s fie realizat n cooperare. Comunicaia ntre procesoare se realizeaz prin intermediul unor tampoane de mesaje. Informaia permanent a structurii software este nmagazinat ntr-o unic baz de date i este accesat de procesoare, prin intermediul administratorului acesteia. Fiecare component a structurii dispune de o main i de un sistem de operare ce i sunt proprii (software prin care se administreaz i se execut programele). Amnunte suplimentare legate de cele cinci procesoare sunt prezentate n continuare. 7.4.3.2 Interfaa cu periferia

Interfaa cu periferia reprezint unicul procesor care comunic direct cu componentele hardware ale sistemului de comutaie, asigurnd astfel independena total a celorlalte procesoare fa de caracteristicile hardware ale acestuia. De aceste caracteristici trebuie s in cont doar interfaa cu periferia, singura component a software-ului care difer obligatoriu de la o familie de sistem de comutaie la alta. Funciile principale ndeplinite de interfaa cu periferia sunt: manevrarea hardware-ului sub controlul procesorului de activiti i explorarea terminaiilor (linii sau trunchiuri). Manevrarea hardware-ului presupune, n principal, recepia comenzilor de aciune n format logic, convertirea lor n aciuni fizice concrete i ntiinarea procesorului de activiti cu succesul / insuccesul aciunii ntreprinse. Astfel, de exemplu, procesorul de activiti poate cere interfeei cu periferia s conecteze un generator de curent de sonerie la o linie trimindu-i acesteia, n format logic, identitile liniei i a generatorului, precum i "coordonatele" ci de legtur ntre acestea. Pentru a le converti n informaii concrete, proprii hardwareului deservit, interfaa cu periferia are nevoie de informaiile permanente ce i sunt furnizate de administratorul bazei de date. Dup ce informaia s-a concretizat,

interfaa cu periferia trece la aciune, realiznd conexiunile cerute, iniiind temporizrile necesare i genernd tensiunile corespunztoare echipamentului hardware n cauz. Dup ce toate operaiile legate de respectiva aciune s-au nfptuit, procesorul de activiti este informat de succesul / insuccesul aciunii ntreprinse. Explorarea (scan-area) terminaiilor este a doua funcie important a interfeei cu periferia. Deoarece terminaiile pot fi de diverse tipuri, interfaa cu periferia i stabilete modul de explorare, de la caz la caz, pe baza informaiilor nscrise n baza de date. Pe msur ce semnalele electrice sunt recepionate de la echipamentele hardware, interfaa cu periferia le convertete n semnalizri. n acest mod, activiti fizice cum este "ridicarea" sau "coborrea" furcii de comutaie a terminalului telefonic, devin semnalizri de genul ANGAJARE / ELIBERARE ("deschiderea aparatului" (off-hook) sau respectiv "nchiderea aparatului" (onhook) n figura 7.23); impulsurile electrice sau semnalele bitonale de numerotare sunt la rndul lor convertite n format binar nainte de a fi transmise procesorului de semnalizri. 7.4.3.3 Procesorul de semnalizri Procesorul de semnalizri este specializat n activitile de interpretare a semnalizrilor provenite de la interfaa cu periferia i de generare a mesajelor logice corespunztoare ctre procesorul de servicii. Interpretarea semnalizrilor se face funcie de informaiile de stare primite de la procesorul de servicii i de datele permanente intermediate de administratorul bazei de date. n urma interpretrii, procesorul de semnalizri genereaz masaje pe baza crora procesorul de servicii stabilete n ce stare se gsete terminalul n cauz. Lanul comunicrilor se nchide prin informarea procesorului de semnalizri cu noua stare a terminalului. Ca exemplu, se poate considera situaia n care un terminal este angajat ntro conexiune. n acest caz, din punct de vedere al procesorului de servicii, terminalul se gsete n starea logic "conversaie" (figura 7.23.); aceast stare este

semnalat i procesorului de semnalizri. Din punctul de vedere al interfeei cu periferia, terminalul se afl n starea fizic "furca ridicat" (off-hook). Coborrea furcii va fi sesizat de interfaa cu periferia care va genera semnalizarea: on-hook. Ca urmare, procesorul de semnalizare iniiaz un temporizator cu ajutorul cruia interpreteaz informaia primit. Astfel, dac temporizarea expir nainte de recepia unui off-hook, atunci se decide c s-a cerut o deconectare i se informeaz procesorul de servicii. n caz contrar, se consider c a fost o btaie n furc (o manevr accidental), care poate avea sau nu o semnificaie pentru procesorul de servicii. 7.4.3.4 Procesorul de servicii Dup cum i spune i numele, procesorul de servicii controleaz modul de desfurare al serviciilor. Pentru a fi degrevat de amnuntele legate de activitile concrete implicate n satisfacerea diverselor servicii, procesorul de servicii are n vedere doar latura abstract (logic) a acestora. n acest mod, un serviciu devine pentru procesorul de servicii un proces care evolueaz n funcie de mesajele primite de la procesorul de semnalizri i genereaz comenzi n format logic, ce sunt transmise procesorului de activiti. Informaiile de stare relative la un anumit serviciu (proces) sunt memorate n baza de date a sistemului. Cu ajutorul acestora, procesorul de servicii decide ce activiti trebuie s desfoare un serviciu atunci cnd procesul de semnalizri trimite un mesaj nou (se poate analiza exemplul din figura 7.23). 7.4.3.5 Procesorul de activiti Procesorul de activiti traduce comenzile abstracte (de genul: conecteaz un generator de ton de disc la terminalul X) primite de la procesorul de servicii, n serii de aciuni care trebuie ndeplinite de interfaa cu periferia. Pentru a realiza cu succes aceast intermediere, procesorul de activiti trebuie s dein anumite informaii relative la protocoalele de uz intern adoptate n cadrul sistemului

respectiv. Pe baza acestor informaii, cererile de activitate formulate de procesorul de activiti devin concrete n ceea ce privete comanda resurselor hardware, rmnnd abstracte doar n privina modului de acionare al acestora. Comunicarea dintre procesorul de servicii, procesorul de activiti i interfaa cu periferia este bidirecional, n acest mod, sistemul este nzestrat cu o reacie invers, care permite verificarea modului n care sunt materializate comenzile. Astfel, absena unui rspuns indic apariia unei probleme, pentru a crei rezolvare, se poate reformula cererea original sau se poate genera o comand de abandonare a activitilor iniiate i de dezactivare a componentelor hardware implicate. 7.4.3.6 Administratorul bazei de date n principat, administratorul bazei de date are rolul de a intermedia accesul celorlalte procesoare la baza de date a sistemului. Deinnd toate detaliile relative la activitile de preluare din baza de date, precum i de nregistrate n aceasta, administratorul bazei de date permite celorlalte procesoare s acioneze, fcnd abstracie de modul de structurare a informaiei. Astfel, o aciune de acces / nregistrare informaie, ntreprins de un anumit proces, se rezum doar la o cerere n acest sens. La baza de date a sistemului poate avea acces i operatorul uman. n acest caz, administratorul bazei de date este nzestrat cu o interfa specializat, prin intermediul creia se pot desfura aciuni de genul: actualizarea informaiei relative la utilizatori i componentele sistemului, modificarea caracteristicilor i serviciilor, supravegherea activitii procesoarelor din sistem, evaluarea gradului de utilizare al procesoarelor i a memoriei. Revenind la figura 7.28 se observ c fiecrui procesor i este dedicat un sistem de operare, OS (operating system). Prin sistem de operare se nelege un ansamblu de programe care coordoneaz activitile unui procesor i schimburile

de mesaje ale acestuia cu restul procesoarelor din sistem. n plus, un sistem de operare asigur i independena software-ului de maina gazd. Aceast independen se creeaz prin interpunerea sistemului de operare ntre aplicaiile componentelor ce alctuiesc software-ul de comutaie i maina gazd (figura 7.29).

Figura 7.29 Poziia sistemului de operare n cadrul unei arhitecturi software Astfel, software-urile devin portabile, adic pot lucra pe diverse configuraii concrete (cu procesare serie sau paralel), fr a fi necesar modificarea lor. Sistemele de operare pot oferi i alte funcii. Printre acestea se pot enumera: monitorizarea traficului, observarea gradului de utilizare a mainii gazd i introducerea de programe elaborate local n ansamblul software-ului cu care este nzestrat sistemul, verificarea i decuplarea acestora n cazul n care se constat o degradare a calitii serviciului n cauz. n concluzie, arhitectura unui software de comutaie depinde de un ansamblu complex de factori ce in att de progresele tehnologice i conceptuale nregistrate n domeniile adiacente (proiectarea i producerea componentelor electronice, ingineria software,...), ct i de obiectivele asumate. n cazul modelului prezentat, principalele obiective au fost: - creterea semnificativ a vitezei de lucru i a capacitii unui sistem de comutaie;

- portabilitatea software-ului; - simplificarea metodologiei de dezvoltare i testare a software-ului. Aceste obiective au fost atinse, n principal, prin: utilizarea unui mediu distribuit de procesare; eliminarea dependenei software-ului de infrastructura hardware modularizarea software-ului; reducerea interdependenei ntre module.

concret i de modul de prezentare a informaiei;