managementul retelelor sdh

5/10/2018 Managementul Retelelor SDH - slidepdf.com

http://slidepdf.com/reader/full/managementul-retelelor-sdh 1/52

CAPITOLUL 4 Managementul reţelelor SDH – teorie şiimplementare practică

4.1 Managementul reţelelor SDH – prezentare teoretică

4.1.1 Prezentare generală

În capitolele precedente au fost prezentate principiile ce guverneazăsistemele de management al reţelelor numerice integrate. Dintre acestea aufost evidenţiate sistemele de management pentru SS7 şi reţelele demanagement ale telecomunicaţiilor (TMN). Folosind ca bază teoretică de

plecare informaţia referitoare la aceste două sisteme poate fi studiat şi cazulparticular al managementului SDH.Reţeaua SDH asigură suportul de transport pentru TMN, utilizând

canalele DCC (”Data Communication Channels” – Canale de comunicaţii dedate) [G.831]. Pe aceste canale, fluxul informaţiilor de management setransmite utilizând un protocol de legătură de date, LAPD [Q.921], un cazparticular al HDLC, asemănător protocolului folosit pentru sistemele SS7,descris şi în această lucrare.

În [VON98] a fost descris modelul fizic şi logic pe care este structurată oreţea SDH. În continuare, va fi descris modelul de management al uneiasemenea reţele.

În fig. 4.1 este prezentat un exemplu de reţea SDH care are încorporat şipropriul sistem de control şi management.

SDH conţine un sistem integrat de management al reţelei, distribuit atâtla nivelul echipamentelor de reţea, cât şi în puncte centrale de gestiune.Transportul informaţiilor de management între toate aceste noduri se poateface fie prin intermediul canalelor de comunicaţie integrate în reţea EO(“Embaded Overhead” – Redundanţă încorporată), fie prin intermediul unor canale auxiliare special destinate acestui scop.

Conform recomandării G.831 a ITU-T managementul automat al SDHtrebuie să aibă capacitatea de a asigura:

interacţiunea automată între reţelele de transport administrate deoperatori de reţea diferiţi;

operarea automată a unei reţele deservite de un operator unic, dar alecărei echipamente provin de la furnizori diferiţi;

optimizarea managementului unui domeniu unic de transport SDH(furnizor unic, operator unic).

Din această perspectivă, obiectivele pe care şi le propune sistemul demanagement al reţelelor SDH pot fi enunţate prin intermediul a şase principiigenerale:

1. capacitatea de a stabili, la cerere, un număr de n căi de transport întredouă puncte de acces al clienţilor;

131



2. capacitatea de a menţine, pentru aceste căi, a unei calităţi înalte aserviciilor, ceea ce presupune şi capacitatea de refacere automată a căilor defecte;

3. capacitatea de a furniza monitorizarea permanentă a performanţelor căilor alocate, atât timp cât acestea se află în serviciu;

4. capacitatea de a asigura o mentenanţă simplă de la distanţă atât îninteriorul unui domeniu gestionat cât şi la graniţa dintre două domenii diferite,ceea ce presupune identificarea şi localizarea echipamentelor defecte;

5. capacitatea de a genera informaţiile privitoare la alocarea şi utilizarearesurselor, informaţii necesare ca suport pentru rutare, contabilizare a costurilor şi planificare a configuraţiei;

6. capacitatea de a furniza suport pentru asigurarea funcţiilor demanagement auxiliare, ca de exemplu cele de: inventar, planificare etc.

Semnifica ţia notaţiilor folosite :

MUX (Multiplexer) = Multiplexor ADM (Add Drop Multiplexer) = Multiplexor de inserţie-extracţieDCS (Digital Cross-connect System) = Sistem digital de interconectareNM (Network Management) = Management de reţea

Succesul stabilirii unei căi între două puncte de acces depinde în modesenţial de respectarea unui mod de identificare unic al acestora din urmă.Aceasta implică existenţa unui număr global unic de identificare pentru fiecarepunct de acces, care să nu se modifice atâta timp cât nodul respectiv se aflăinclus în reţea. Numărul de identificare trebuie să conţină informaţii pe bazacărora să poată fi determinat operatorul căruia îi aparţine nodul respectiv, cât şireţeaua din care face parte. Setul identificatorilor punctelor de acces din cadrulunei reţele trebuie să asigure o schemă unică de identificare, independentă de

132

ADM

NM

…

MUX

NM

…

MUX

NM

…

DCS

NM

… …

a f l u

e n

ţ i

a f l u

e n

ţ i

c onexiune fizică

Fig. 4.1. Exemplu de sistem de management al SDH

Informaţii de redundanţă încorporată

Canale auxiliare dedicatemanagementului de reţea



schemele similare utilizate în alte reţele. Modul de construire a acestei schemede identificare este reglementat în [E.164], iar localizarea şi codareaidentificatorilor punctelor de acces este descrisă în [G.709].

În cadrul unei reţele de management a SDH, funcţiile primare demanagement se ocupă, în principal, cu stabilirea, validarea, monitorizarea,

protejarea şi refacerea legăturilor între două noduri de acces.Pentru stabilirea căilor, structura de control trebuie să asigure prelucrarea şitransportul mesajelor între procesele de control diferite implicate. Ea opereazăcu două tipuri distincte de mesaje, specifice oricărei structuri de controlierarhizată pe nivele funcţionale (fig. 4.2):

mesaje transferate între procesele de control situate pe nivele înalte şiprocesele controlate de acestea, situate pe nivele de bază;

mesaje transferate între procesele pereche situate la acelaşi nivelierarhic.

Poate fi făcută o diferenţiere între modul de stabilire a unei noi căi între doioperatori de reţea distincţi sau în cazul unei aceleiaşi reţele deservite de un

unic operator.Atunci când se stabileşte o cale între doi operatori de reţea distincţi pot fifolosite două protocoale diferite, fie cel de rutare “pas cu pas” , fie cel al rutării sursei , iar în cazul reţelelor deservite de un singur operator există trei metodedistincte de stabilire a unei căi.

Metoda centralizată, presupune utilizarea unui punct central unic deprocesare, iar mesajele folosesc alte căi de transfer decât cele utilizate deelementele reţelei.

Metoda rutării “pas cu pas” , presupune folosirea unor protocoale derutare comune mai multor sisteme de semnalizare. Mesajele de control dintrenivelele funcţionale implicate aparţin unei aceleiaşi entităţi de procesare.

133

Nivelfizic

Nive

lse

cţiune

Ni v

elsecţiune

Nivelcale

regen

erare

multiplexare

Fig. 4.2. Structura de control pentru stabilirea unei căi



Aceasta poate fi încorporată elementelor de reţea şi atunci va folosiprotocoalele proprii mediului SDH [Q.784], descrise în continuare, fie va fiexternă acestora şi atunci va folosi modul de adresare descris în [M.3010 şiG.774].

Metoda rutării sursei , în acest ultim caz, atât protocoalele folosite, cât şi

ruta aleasă vor fi stabilite la primul nod, acela care generează mesajul. Deasemenea, dacă controlorul de procesare se află în interiorul nodului vor fiutilizate protocoale specifice SDH [G.784], iar în cazul în care acesta esteextern nodului, atunci va fi utilizat modul de adresare specific TMN. Aceastămetodă nu poate determina, în afara sub-reţelei în care este conţinut nodulsursă, rutele utilizate, la acest nivel fiind necesare protocoale distincte destabilire a legăturii între operatori.

În capitolul precedent a fost descris atât sistemul de semnalizare nr. 7, carestă la baza semnalizărilor dintre două reţele diferite, cât şi sistemul TMN, acărui metodologie de transfer a mesajelor poate fi utilizată cu succes în toate


ER A, ER B Element de Reţea A, BOA Obiect AdministratFER Funcţie Element de ReţeaDM Dispozitiv de Mediere

SO Sistem de OperaţiiFMA Funcţie de Management la nivel AplicaţieFCM Funcţie de Comunicaţii pentru Mesaje

cele trei metode de mai sus, în cazul în care acestea folosesec drept nod decontrol un nod situat în afara reţelei de transport a SDH. În fig. 4.3 esteprezentat un exemplu de configuraţie funcţională SDH specifică procesului destabilire a unei căi de comunicaţie între un controler de proces situat în afaranodurilor A şi B între care este realizată calea.

134

Fig. 4.3. Exemplu configuraţie management SDH implicată în stabilirea unei căi

FCM

FER-FMA

OA

FCM

FER-FMA

OA

FCM

DM-FMA

FCM

SO-FMA

ER A ER B DM SO

Qx Q3



Odată ce o cale a fost stabilită conform uneia din procedurile enunţate maisus, ea va trebui validată, ceea ce prespune transmiterea în bandă a codului deidentificare asociat punctului de acces conectat. Acesta va trebui validat lacelălat capăt al legăturii. Odată ce calea sau secţiunea a fost stabilită şi validatăea va fi permanent monitorizată din punct de vedere al integrităţii mediului

transmis. Monitorizarea se poate realiza utilizând redundanţa de cale sau desecţiune potrivită, aceasta fiind apoi permanent comparată cu o valoare limită.Dacă performanţele transmisiunii vor scădea sub acest prag, atunci va fideclarată apariţia unui nou defect. În cazul în care calea sau secţiunearespectivă sunt protejate atunci va fi declanşată procedura automată derefacere a legăturii, conform [G.803].

Au fost descrise până acum obiectivele generale ale managementului SDH. În continuare, va fi prezentat modul în care aceste obiective pot fi realizate.

4.1.2 Suport de transmisiuni pentru managementul SDH

Aplicaţiile de management al SDH pot fi clasificate după aria de activitate,ca fiind de două tipuri:

aplicaţii de management la nivel de reţea; aplicaţii de management la nivel de echipament.

După cum a fost prezentat la începutul acestui capitol, informaţiile demanagement pot folosi drept suport fizic pentru transmitere fie canalele decomunicaţie integrate în antetul cadrului de transport, fie canale externemediului SDH.

Pentru a localiza în mod corect canalele fizice folosite ca suport pentrutransmiterea informaţiilor de management, în fig. 4.4 a fost prezentată

redundanţa de secţiune SOH (“Section Over Head”) pentru cadrul primar STM-1.Informaţiile de management încorporate în cadrul SDH (EO) pot fi la nivelul

lor tributare unui protocol orientat pe bit sau pe mesaj. În primul caz suntreprezentate prin anumiţi octeţi din SOH, pe care îi vom descrie în momentultrecerii în revistă a funcţiei managemetului defectărilor. În cazul în carecomunicaţia foloseşte un protocol orientat pe mesaje, sunt folosiţi biţii D1 ÷

D12, ceea ce înseamnă 12 canale distincte, fiecare cu debitul de 64 kbps, deciun debit total de 768 kbps.

Primele trei canale, D1 ÷ D3, asigură un debit de transport sincron de 192kbps, dedicat informaţiilor OAM privitoare la echipamentele terminale ale

secţiunii de regenerare. Următoarele 9 canale, D4 ÷ D12, alcătuiesc un canalde comunicaţii de date (“DCC – Data Communication Channel”) cu debitul de576 kbps, dedicat transportului informaţiilor OAM specifice secţiunii demultiplexare.

1 2 3 4 5 6 7 8 9

R S O H 1 A1 A1 A1 A2 A2 A2 J0 NU NU

2 B1 X X E1 X X F1 NU NU

3 D1 X X D2 X X D3 X XPTR. 4 H1 h1 h1 H2 h2 h2 H3 H3 H3

135



M S O H 5 B2 B2 B2 K1 X X K2 X X

6 D4 X X D5 X X D6 X X

7 D7 X X D8 X X D9 X X

8 D10 X X D11 X X D12 X X

9 S1 Z1 Z1 Z2 Z2 M1 E2 NU NU


RSOH (Regeneration Section Over Head) = Redundanţa secţiunii de regenerareMSOH (Multiplexing Section Over Head) = Redundanţa secţiunii de multiplexare

Protocolul utilizat pentru transferul informaţiilor pe aceste canale este detipul orientat pe mesaje, numit LAPD (“Link Access Protocol channel D” –Protocol de acces legătură pe canal D), definit în [Q.920 şi Q.921].

Acest protocol este de nivel 2, legătură de date, dacă ne raportăm laierarhia stratificată OSI a sistemelor SDH. Scopul său este de a transportainformaţii între entităţiile nivelului 3 de-a lungul interfeţelor ISDN utilizator-reţea,folosind canale de tip D. Este un protocol duplex, independent de rata detransmisie a canalului folosit. Nivelul 3 al arhitecturii OSI solicită servicii de lanivelul legătură de date prin intermediul primitivelor de servicii. În acelaşi felnivelul 2 comunică cu nivelul fizic. Primitivele schimbate între nivelul legătură dedate şi nivelele adiacente acestuia sunt clasificate după patru tipuri distincte:

primitive CERERE; primitive INDICAŢIE;

primitive RĂSPUNS; primitive CONFIRMARE. În fig. 4.5 este prezentată o posibilă secvenţă a modului în care acţionează

aceste primitive.Primitiva CERERE este utilizată atunci când nivelul superior cere un

serviciu de la nivelul imediat inferior.Primitiva INDICAŢIE este utilizată de nivelul furnizor de servicii atunci când

acesta doreşte să anunţe nivelul imediat superior de iniţierea unei activităţireferitoare la serviciul solicitat.

Primitiva RĂSPUNS este utilizată de un anumit nivel pentru a confirmanivelului imediat inferior că a recepţionat de la acesta o primitivă de tip

INDICAŢIE.Primitiva CONFIRMARE este utilizată de nivelul furnizor de servicii pentru aconfirma îndeplinirea serviciului solicitat.

136

Fig. 4.4. Structura SOH pentru cadrul STM-1

Nivel 3 Nivel 3

CONFIRMARE CERERE INDICAŢIE RĂSPUNS

PAS



Protocolul LAPD include funcţii specifice nivelului 2 din ierarhia unui sistemOSI, după cum urmează:

furnizarea uneia sau mai multor conexiuni de tip legătură de date pecanalul D;

includerea unei secvenţe de control care să permită respectarea uneiordini corecte în secvenţa sosirii cadrelor la recepţie;

detecţia erorilor de transmisie, de format şi operaţionale survenite pe oconexiune tip legătură de date;

refacerea informaţiilor utile în cazul apariţiei erorilor; anunţarea entităţilor de management în cazul apariţiei unor erori ce nu

mai permit refacerea informaţiei; controlul fluxului de informaţie.

Deci suportul fizic pentru canalele ECC este constituit de canalale DCC,care folosesc un protocol de comunicaţie de tip LAPD. Pentru a asigura un bun

suport logic pentru funcţiile de management, trebuie implementate şi anumitefuncţii de control pentru canalele ECC. Astfel, funcţiile de management ale ECCtrebuie să îndeplinească următoarele condiţii:

refacerea principalilor parametri ai reţelei ce asigură o funcţionarecompatibilă (mărimea pachetelor, calitatea serviciilor, mărimea ferestrei deretransmisie etc.);

stabilirea unei rutări a mesajelor între nodurile DCC; managementul adreselor de reţea; refacerea stării operaţionale a DCC la nodurile aflate în trafic; capacitatea de a permite sau interzice accesul la canalele DCC.

Suplimentar faţă de aceste canale de management încorporate în antetul

cadrelor SDH, în acelaşi scop mai pot fi folosite şi canale externe de conectarela managerul principal al reţelei. Acest mod de abordare se dovedeşte extremde util atunci când nu sunt încă interconectate toate inelele SDH, fiind astfelimposibilă folosirea suportului propriu de management. Canalele externe ce vor conecta nodurile SDH la punctul principal de control pot folosi două tipuri deinterfeţe cu inelele SDH:

interfaţa QB3, tip Ethernet 802.3, pentru cazul în care distanţele deinterconectare sunt reduse;

interfaţa QB2, tip X25, pentru cazul în care distanţele de interconectaresunt mari.

Folosirea acestor tipuri de interfeţe are un dublu scop:

137

Fig. 4.5. Secvenţă de acţionare a primitivelor

Nivel 2 Nivel 2

Protocol punct-la-punct la nivelul Legătură de Date

PAS – Punct de Acces la Serviciu



pot interconecta între ele facilităţile interne de management alenodurilor DCS sau MUX;

pot conecta aceste facilităţi la un punct principal de management,extern reţelei de transport.

Unul din principalele avantaje ale modului de management al unei reţele

SDH este faptul că are încorporat direct în mediul de transmisuni suportulpentru TMN, prin intermediul canalelor DCC. Folosirea unui sistem extern detransport pentru TMN, deşi extrem de utilă mai ales în faza de instalare ainelelor SDH, poate ridica probleme deosebite de interfaţare, dublate deinconvenientul că astfel se pierde din caracterul integrat al soluţiei oferite pentruacest tip de management.

În următorul paragraf va fi descris modul de implementare a funcţiilor demanagement specifice TMN în cazul particular al SDH.

4.1.3 Funcţiile de management al SDH

Funcţiile de management ale SDH respectă clasificarea din RecomandareaM.3010 a ITU-T pentru TMN, clasificare descrisă şi în această lucrare. Conformacesteia avem următoarele categorii de funcţii de management:

funcţia de management al defectărilor; funcţia de management al performanţelor; funcţia de management al siguranţei; funcţia de management al configuraţiei; funcţia de management al calităţii.

Modul de implementare a acestor funcţii de management este unul ierarhic,pornind de la structura de control prezentată în fig. 4.2, structură care respectă

stratificarea logică specifică SDH [G.803]. În fig. 4.6 a fost prezentată ierarhiade management proprie SDH. În continuare, vor fi descrise principalele funcţii de management specifice

SDH.

A. Funcţia de management al defectărilor

Funcţia de management al defectărilor acţionează atât la nivel de reţea, câtşi la nivel de echipament, la fel ca toate celelalte funcţii de management.

La nivel de reţea principalul său obiectiv este de a detecta şi identificaechipamentele defecte. La nivel de echipament acţiunea sa este mai complexă

şi presupune detectarea defectărilor, generarea şi monitorizarea semnalelor dealarmă, testarea reţelei.Fiecare echipament din reţea, tratat din punct de vedere obiectual ca un

ER, trebuie să aibă capacitatea să genereze automat semnale de alarmă sprecentrul de management atunci când anumite evenimente/condiţii neacceptabileapar în funcţionarea sa sau sunt sesizate în fluxurile externe pe care acesta lerecepţionează. Aceste evenimente sau condiţii trebuie clasificate, de cătremanager, ca importanţă, în două mari categorii:

evenimente grave care trebuie raportate imediat, automat, de cătreechipament;

138



restul evenimentelor ce pot apărea, acestea trebuind stocate şiraportate atunci când echipamentul este interogat de către manager.

Această clasificare încearcă să minimizeze impactul pe care l-ar putea aveaasupra încărcării traficului de management apariţia mesajelor referitoare ladefectări sau proaste funcţionări.


RSTE (Regeneration SectionTerminal Equipment)

= Echipament terminal al secţiunii deregenerare

MSTE (Multiplexing Section TerminalEquipment)

= Echipament terminal al secţiunii demultiplexare

HOPTE

(High Order Path TerminatingEquipment)

= Echipament terminal al căii de ordinsuperior

LOPTE

(Low Order Path TerminatingEquipment)

= Echipament terminal al căii de ordininferior

Din aceste motive, sistemul de management al SDH trebuie să fie capabilsă îndeplinească următoarele funcţii dedicate controlului alarmelor:

raportarea automată a alarmelor; posibilitatea de a solicita transmiterea alarmelor; posibilitatea de a bloca sau nu transmiterea alarmelor pe ECC; posibilitatea de a valida sau invalida funcţia de solicitare a alarmelor; posibilitatea de a valida sau invalida funcţia de tranmsitere automată a

alarmelor. În cele ce urmează vom trece în revistă principalele condiţii de eroare,

precum şi semnalele de eroare şi alarmă ce pot fi generate de echipament către

sistemul de management.139

Fig. 4.6. Ierarhie de management SDH

RSTE RSTE

RSTE

RSTE

RSTE

RSTE

RSTE

RSTELO POH

RSOH

MSOH

HO POH

Nivel secţiune deregenerare

Nivel cale

Nivel secţiune demultiplexare



Condiţii de eroare

LOS ( Loss O f S ignal) – Lipsă semnal

Atunci când echipamentul nu recepţionează, înainte de de-scrambler, un bitde 1 pentru o durată mai mare de 100 µ sec, se declară defect lipsă de semnalşi dacă defectul persistă mai mult de 2 sec, se generează un semnal de alarmăLOS spre sistemul de management.

În sens invers, pentru a se declara lipsă defect este necesară recepţia a celpuţin două module de transport corecte consecutiv. După alte 10 sec defuncţionare corectă este anulată şi condiţia de eroare, iar echipamentulresetează semnalul de alarmă, trimiţând spre sistemul de management unmesaj de ieşire din alarma respectivă.

OOF ( O ut O f F rame) - Desincronizare

În cazul în care timp de 625 µ sec nu este detectată secvenţa corectă desincronizare (octeţii A1 şi A2 din redundanţa de secţiune RSOH) se declarădefect de OOF. Pentru a se declara reintrarea în sincronism trebuie detectatedouă secvenţe de sincronizare corecte consecutive.

LOF ( Loss O f F rame) – Pierderea sincronismului

Dacă indicaţia de alarmă OOF există pentru mai mult de 3 sec se declarăLOF. Dacă acesta persistă mai mult de 2.5 sec atunci echipamentul trece în

condiţie de eroare, activând indicatorul LOF, simultan cu trimiterea unui semnalde alarmă specific spre sistemul de management.Pentru a fi înlăturat defectul LOF trebuie ca echipamentul să stea cel puţin 3

sec fără eroare OOF. După alte 10 sec fără alarmă, condiţia de alarmă esteresetată, iar spre sistemul de management este trimis un mesaj de anulare acondiţiei de eroare.

LOP ( Loss O f P ointer) – Pierderea pointerului

Defectul LOP poate fi detectat în două cazuri distincte: sunt recepţionaţi consecutiv cel puţin doi pointeri incorecţi, adică cu

salturi mai mari de o unitate; se recepţionează consecutiv 10 indicaţii de încărcătură nouă (NDF –

New Data Flag – Indicator încărcătură nouă).După mai mult de 2.5 sec de eroare este declarată condiţie de eroare LOP

şi se transmite alarmă spre sistemul de management.Pentru înlăturarea defectului este necesară recepţionarea a trei pointeri

consecutivi cu valori corecte şi NDF-uri normale. După alte 10 sec de ladispariţia defectului este înlăturată şi condiţia de eroare, ceea ce conduce laresetarea semnalului de alarmă şi la transmiterea unui mesaj de anulare aalarmei spre sistemul de management.

140



În afara acestor posibile defecte mai există şi altele mai puţin importantesau mai rar întâlnite.

Echipamentul de reţea monitorizează şi propria sa funcţionare, în modsimilar modului în care monitorizează defectele de semnal. Aceasta presupunemonitorizarea blocului de alimentare, blocului de procesare, blocului memoriilor,

precum şi altor blocuri funcţionale. Modul în care se realizează aceste operaţiisunt specifice producătorului. La ieşirea din condiţiile normale de funcţionarepentru unul din aceste blocuri este generat un semnal optic de avertizare locală,dublat de transmiterea unui mesaj corespunzător de alarmare spre sistemul demanagement.

Protocolul de comutare automată a protecţiei

În secţiunea anterioară au fost prezentate principalele condiţii de eroare pecare le poate monitoriza sistemul de management al SDH şi modul în careacesta reacţionează la detectarea unei condiţii de eroare. Pentru a puteaasigura o funcţionare continuă, la parametrii impuşi, a unei secţiuni demultiplexare sunt prevăzute aşa numitele canale de rezervă. Un canal derezervă poate fi folosit ca protecţie pentru mai multe secţiuni active, iar declanşarea comutării pe acest canal trebuie să se poată realiza simultan laambele echipamente terminale.

Acest protocol (APS – “Automatic Protection Switching”) se declanşeazăautomat la îndeplinirea uneia din următoarele trei condiţii:

degradarea peste o anumită limită a calităţii semnalului; apariţia pe secţiunea respectivă a unor condiţii noi de eroare; primirea unor comenzi externe de comutare forţată a protecţiei.

Pentru controlul acestui protocol există un bloc dedicat pentru managemental protecţiei, care foloseşte drept suport de transport pentru informaţia necesarăocteţii K1 şi K2 din MSOH. Trebuie luată în seamă şi probabilitatea eronăriichiar a acestor octeţi, ceea ce trebuie să conducă la generarea unei condiţii deeroare specifică.

Semnale de alarmă şi eroare

După cum a fost prezentat în secţiunea dedicată condiţiilor de eroare, atuncicând echipamentul detectează o condiţie de eroare, după un timp prestabilit,transmite un mesaj de alarmă sau de eroare spre sistemul de management.

În principal, în SDH sunt două mari categorii de semnale de alarmă, dupădirecţia spre care sunt generate: AIS (”Alarm Indication Signal” – Semnal de indicare a unei alarme) –

este transmis spre echipamentul aflat pe sensul de emisie, deci în aval; RDI (”Remote Defect Indication” – Indicator de defect la un terminal

îndepărat) – este transmis amonte, adică spre sistemul de management.La rândul lor, semnalele AIS pot fi împărţite în trei categorii: MS_AIS: este transmis în general atunci când sunt detectate erori de

tip LOS, OOF sau OOF; HO_AIS: este transmis în principal la detectarea pierderii pointerului la

cadrele din calea de ordin superior, deci la apariţia defectului HO_LOP;

141



LO_AIS: se generează în condiţii similare cu semnalul HO_AIS, dar sereferă la pierderea pointerului pentru cadrele dintr-o cale de ordin inferior, deciatunci când apare defectul LO_LOP.

Pentru semnalele de tip RDI pot fi identificate în mod similar trei sub-tipuridistincte, corespunzătoare celor trei nivele de management:

MS_RDI: este transmis nodului de origine al secţiunii de multiplexare,atunci când în terminal sunt stabilite una din cele trei condiţii de eroare: LOS,LOF sau OOF;

HO_RDI: este transmis amonte dacă s-a detectat pe calea de ordinsuperior o condiţie HO_LOP sau dacă la acest nivel au fost recepţionate dinamonte MS_AIS sau HO_AIS;

LO_RDI: este generat dacă la nivelul căii de ordin inferior a fostdetectat un defect de pierdere de pointer, deci LO_LOP sau în cazul în care afost recepţionat din amonte unul din semnalele de eroare HO_AIS sau LO_AIS.

Referitor la semnalele de eroare, acestea nu sunt transmise decât înamonte, spre echipamentul de la care se recepţionează fluxul informaţional şisunt denumite REI (”Remote Error Indicator” – Indicator de eroare la terminalul îndepărtat).

Aceste tipuri de mesaje pot fi la rândul lor catalogate după nivelul fizic de lacare sunt generate, astfel:

MS_REI: reprezintă un retur distant la BIP_24, fiind generat la nivelulsecţiune de multiplexare;

HO_REI: reprezintă un retur distant la BIP_8, fiind generat la nivelul căiide ordin superior;

LO_REI: reprezintă un retur distant la BIP_2, fiind generat la nivelul căiide ordin inferior.

Testarea reţelei

Această facilitate a funcţiei de management al defectărilor este foarte utilă în identificarea unor nefuncţionalităţi apărute în operarea reţelei. Poate fidivizată în trei sub-funcţii diferite de mentenanţă şi întreţinere [G.784]:

funcţii de acces la reţea; funcţii de diagnosticare; funcţii de rebuclare.

Cu ajutorul funcţiilor de acces pot fi monitorizate şi testate echipamenteledin reţea, prin conectare locală sau distantă la facilităţile interne de testare ale

acestora.Diagnosticarea permite realizarea unei analize a rezultatelor obţinute înetapele de accesare şi culegere a datelor de la echipamente.

Prin funcţiile de rebuclare pot fi testate separat, progresiv, prin izolare, toatetronsoanele unei reţele SDH, fiind foarte utile pentru funcţiile de diagnosticare.

B. Funcţia de management al performanţelor

Această funcţie are drept scop monitorizarea continuă a performanţelor reţelei, utilizând ca principale metode fie citirea parametrilor fizici ai reţelei, fiecolectarea biţilor de redundanţă conţinuţi în antetul cadrului SDH. Au fost

142



acceptate două intervale de măsură [G.783 şi G.784], un interval minim de 15minute şi altul de 24 h. Parametrii ce urmează a fi monitorizaţi sunt specificaţi în[G.783], în continuare fiind prezentaţi doar cei mai importanţi dintre aceştia[conform tab. A-3/G.784]:

CV Code Violation = Violare a coduluiES Errored Second = Secundă eronatăSES Severly Errored Second = Secundă sever eronatăUAS UnAvailable Second = Secundă indisponibilă (nefuncţională)PSC Protection Switching

Count= Număr de comutări ale protecţiei

PSD Protection SwitchingDuration

= Durata comutării protecţiei.

Pentru o analiză pertinentă a datelor privitoare la performanţa reţelei estenecesară asigurarea memorării unei anumite istorii funcţionale a obiectuluimonitorizat. Pentru acest scop au fost definţi un număr distinct de regiştri,

asociaţi celor două ferestre principale de monitorizare: cea de 15 minute şi ceade o zi. Pentru fiecare fereastră a fost definit câte un registru pentru situaţiacurentă, un altul pentru situaţia anterioară şi un număr nedefinit de regiştripentru ultimele n intervale recente. Toţi aceşti regiştri pot fi citiţi la cerere sau înmod regulat, actualizarea sau citirea informaţiei făcându-se în mod obligatoriufără pierderi.

Pentru toate mărimile monitorizate au fost stabilite nişte limite de variaţiemaxime, depăşirea acestora atrăgând automat după sine generarea unor mesaje de alarmă sau de eroare, după cum a fost deja descris în secţiuneaanterioară.

Această funcţie de management al performanţelor oferă informaţii foarteutile atât pentru funcţia de defectări cât şi pentru funcţia de management alconfiguraţiei, care va fi prezentată în continuare.

C. Funcţia de management al configuraţiei

Managementul configuraţiei se referă la toate acele funcţii care asigură obună configurare a resurselor sistemului de transport şi este util atât în etapa deinstalare a reţelei, cât şi în etapa operaţională. În etapa de instalare nu există încă operaţional suportul de transmisiuni pentru sistemul de management, decisunt folosite soluţiile proprietare ale furnizorului, necesare punerii în funcţiune a

întregului sistem. În etapa operaţională deja trebuie stabilite anumite metode decontrol a parametrilor reţelei în vederea optimizării performanţelor acesteia.Principalul instrument aflat la dispoziţia managerului pentru optimizareaconfiguraţiei este funcţia de comutare a protecţiilor. Pentru o folosire uşoară şicorectă, aceste funcţii de comutare trebuie să poată funcţiona în patru regimuridistincte:

regim cu comandă de comutare manuală a intrării/ieşirii din funcţiune acircuitelor de protecţie;

regim cu comutare forţată a intrării/ieşirii din funcţiune a circuitelor deprotecţie;

regim de blocare a comutării circuitelor de protecţie;

143



regim cu comandă de comutare automată a intrării/ieşirii din funcţiune acircuitelor de protecţie (cunoscut ca APS).

Aceste trei funcţii de management prezentate mai sus sunt cele maiimportante şi ca atare sunt standardizate în recomandarea G.784 a ITU-T.

În cele ce urmează vom prezenta protocoalele de transfer ale mesajelor de

management de-a lungul reţelei.

4.1.4 Stiva de protocoale pentru canalele de transport al informaţiei demanagement

Deoarece SDH este construit conform recomandărilor ISO referitoare lasistemele deschise, aceasta abordare se va reflecta şi în modul în care esteconstruită stiva de protocoale specifică transferului informaţiei de management.

Au fost prezentate deja în capitolul 2 modul orientat pe obiecte de abordareal managementului sistemelor OSI, precum şi conceptul de TMN, utilizat înreţelele de telecomunicaţii.

Managementul reţelei SDH se bazează la rândul lui pe aceleaşi concepteorientate pe obiecte specifice sistemelor OSI, putând fi tratat ca un caz specialal TMN.

Pentru exemplificare, în fig. 4.7 este prezentat modelul de stivă deprotocoale pentru canalele de transport al informaţiei de management.

Nivelul fizic este constituit de canalele DCC, care operează la viteza de 192kbps în secţiunea de regenerare, folosind octeţii D1 ÷ D3, iar în secţiunea demultiplexare operează la 576 kbps, utilizând pentru aceasta octeţii D4 ÷ D12.

La nivelul 2, cel al legăturii de date este folosit protocolul LAPD, conform[Q.921]. Acesta asigură un transfer punct-la-punct al NSDU-urilor, utilizând un

singur canal logic între cele două noduri.Există două modalităţi distincte de abordare, specifice acestui protocol,utilizând fie UITS (“Unacknowledged Information Transfer Service” – Serviciude transfer neconfirmat al informaţiilor), fie AITS (“Acknowledged InformationTransfer Service” – Serviciu de transfer al informaţiilor cu confirmare).

144

CMISEACSE/ROSENivel 7 →

X.216 şi X.226Nivel 6 →

X.215 şi X.225Nivel 5 →

LAPD [Q.921]Nivel 2 →

ISO 8073/AD2Nivel 4 →

ISO 8473/AD3Nivel 3 →



La nivelul 3, nivelul reţea, este utilizat un mod de transfer fără conexiune,NPDU-urile fiind transportate ca datagrame. Pentru a putea transferainformaţiile de la nodul sursă la cel destinaţie, este necesar ca fiecare nod dinreţea să poată lucra fie ca nod intermediar, fie ca nod final. În acest fel, nodurileintermediare pot genera, la rândul lor, informaţii de control al rutării, necesarerutării NPDU-urilor.

Pentru nivelul 4, cel de transport, este utilizat un protocol orientat peconexiune, specificat în recomandarea ISO 8073. Acesta este un protocol detransport clasa 4 (“TP class 4” ).

Pentru nivelele 5 şi 6 specificaţiile funcţionale sunt cele descrise înrecomandările X.215 şi X.225 pentru nivelul sesiune şi X.216 şi X.226 pentrunivelul prezentare.

La nivelul 7 sunt situate funcţiile de management, după cum este descrisşi-n capitolul din acestă lucrare dedicat TMN-ului. În fig. 4.8 este prezentatnivelul aplicaţie şi protocoalele componente ale acestuia.

Serviciile ACSE sunt utilizate la iniţierea sau închiderea unei asociaţii între

două aplicaţii corespondente. Odată stabilită o asociaţie, ea este folosită pentrua putea fi transmise mesaje de management la serviciile CMISE.Pentru operaţiile la distanţă sunt utilizate ROSE care permit unui sistem să

invoce derularea unei operaţii pe un alt sistem şi să ceară, de asemenea, să fieinformat despre modul în care se desfăşoară operaţia comandată.

145

SM-ASE

CMISE

ROSEACSENivelAplica

ţie

Fig. 4.8. Protocoale de comunicaţie SDH la nivel aplicaţie

DCCNivel 1 →

Fig. 4.7. Stivă de protocoale pentru ECC



La nivelul cel mai înalt este situat CMISE, ca parte componentă a CMIP,rolul său fiind de a furniza servicii de transfer a informaţiilor de management de-a lungul întregii reţele de canale ECC. Alegerea acestei clase de servicii pentrumanagementul SDH impune o metodă orientată pe obiecte de tratare acomponentelor reţelei.

Pentru managementul reţelei SDH, CMISE oferă următoarele primitive şiservicii asociate acestora: crearea de obiecte →primitiva CREATE; ştergerea de obiecte →primitiva DELETE; definirea atributelor obiectelor →primitiva SET; redefinirea atributelor obiectelor →primitiva GET; comanda unor operaţii →primitiva ACTION; recepţionarea de rapoarte de la obiecte →primitiva EVENT_REPORT.

Pentru descrierea obiectelor şi a atributelor specifice acestora este utilizatstandardul ASN.1.

Se poate afirma, la finalul prezentării, că managementul SDH este oaplicaţie a TMN, aplicaţie ce respectă particularităţile transmisive ale mediuluifolosit drept suport.

În continuare, este prezentat o metodă practică de implementare, realizatăde către autor, a unei părţi din sistemul de management al unei reţele SDHimplementate la noi în ţară. Au fost folosite drept suport canale exterioaresistemului de transmisiuni, iar protocolul realizat este o adaptare a protocoluluiLAPD la condiţiile particulare ale aplicaţiei respective.

Paragraful următor constituie, de fapt, o parte a unui raport tehnic de produsprezentat de autor la terminarea fazei de colaborare pentru acest sistem cuINSCC-Bucureşti, în decembrie 1998.

4.2 Sistem de management pentru o reţea SDH – implementarepractică

4.2.1 Descriere generală a sistemului

După descrierea principiilor ce stau la baza managementului reţelelor SDH, realizată în secţiunea anterioară, vom prezenta acum un mod practic derealizare a unui sistem de management dedicat unei reţele SDH, funcţională laora actuală în cadrul reţelei de fibră optică a RomTelecom. Sistemul a fostproiectat pentru a asigura principalele funcţii de management ale tronsonului Bale reţelei de transmisiuni pe suport de fibră optică, realizat cu echipamenteFujitsu. În fig. 4.9 este prezentată configuraţia reţelei de transmisuni pentru carea fost implementat acest sistem de management.

146

Staţie de comutaţie centrală

Legend ă



Sistemul manevrează cu fluxuri tributare de 2 Mbit/s, 34 Mbit/s şi 140Mbit/s care sunt apoi inserate într-un inel de transport SDH, la nivelul întregiiţări. Deci, deşi acest tronson este în sine o aplicaţie de transport plesiocronă,pe suport de fibră optică, poate fi tratată din punctul de vedere al scopului finalca făcând parte dintr-un sistem SDH. Tipurile de alarme, configuraţii de lucru şimodul de monitorizare sunt specifice sistemului SDH din care fac parte şi aufost descrise din punct de vedere teoretic în secţiunea anterioară.

Echipamentele care asigură suportul de transmisuni pe fibră optică suntde următoarele tipuri: echipament de multiplexare digitală 2M/34M (M13 MUX); echipament de multiplexare digitală 34M/140M (M34 MUX); echipament terminal de fibră optică 140 Mbit/s (140M OLTE); echipament regenerator optic (140M OLRE).Fiecare dintre aceste echipamente au o structură modulară care le permite

o mare flexibilitate în operare, monitorizare şi mentenanţă. Din punctul devedere al sistemului de management ele au fost tratate ca Elemente de Reţea,atât ân ansamblu, cât şi la nivel de cartelă, constituind astfel clasa obiectelor deadministrat (după cum am arătat în cap. 1 şi cap. 2). În fig. 4.10 am figurat

147

GALAŢI

SASCUT

ADJUD

FOCŞANI

BRĂILA

ÎNSURĂŢEI

SLOBOZIA

BACĂU

AFUMAŢI

URZICENI CĂZĂNEŞTIŢĂNDĂREI

FETEŞTICERNAVODĂ

MEDGIDIA

CONSTANŢABUCUREŞTI

Staţie regenerator

Staţie intermediară

Staţie terminală

Fibră optică de 140 Mb/s

Fig. 4.9. Configuraţia tronsonului B de fibră optică



structura unor asemenea blocuri şi cartele din perspectiva sistemului demanagement.

Fiecare dintre aceste obiecte trebuie să poată fi incluse în sistemul demanagement, deci să li se poată aplica funcţiile de management: deconfigurare, de defectare şi de performanţă. Sistemul trebuie să fie capabil săconfigureze echipamentele în mod optim, să le monitorizeze permanentperformanţele şi să detecteze rapid orice defect apărut în funcţionareaacestora.

4.2.2 Baza de date a sistemului de management

Pentru a putea asigura toate aceste funcţiuni a fost creată o bază dedate relaţională, inspirată din cerinţele impuse de OSI pentru MIB şi careconţine principalele mărimi folosite de funcţiile de management. Baza de dateconţine astfel următoarele tipuri de tabele:

tabela de STAŢII; tabela de UNITĂŢI; tabela de TIPURI; tabela de CANALE; tabela de CODURI_ALARMĂ; tabela de ALARME;

148

B1 B1 B1

B2

B3

B2

B3 B3

B2

rack 1 rack 2 rack 3

E-SV E-SV E-SV

cartele

conector MPT

blocuriBloc 2

Bloc 1

Bloc 3

Fig. 4.10. Structura şi localizarea obiectelor de management

MPT (Maintenance Portable Terminal – Terminal portabil de mentenanţă)



tabela de FUNC_SPEC; tabela de UTILIZATORI.

Tabela de STAŢII

Structura tabelei de STAŢII este prezentată în tab. 4.1.

Nr. crt. CÂMP TIP CÂMP1. ID_STAŢIE integer 2. NUME_STAŢIE text3. ID_CANAL integer 4. NR_RACKURI integer 5. NR_RACKURI_DIST integer 6. ADR_PROTOCOL integer 7. ECA_INSTALAT integer 8. ID_DIST_ST integer 9. NR_RACK_CON_DIST integer

Semnificaţia câmpurilor folosite în cadrul tabelei de STAŢII esteurmătoarea:

ID_STAŢIE - este câmpul de identificare a staţiilor, fiecărei staţii fiindu-iasociat ca identificator un număr întreg;

NUME_STAŢIE - asociază fiecărei staţii un nume în clar, care poate fiafişat pe ecranul consolei de management;

ID_CANAL - indică canalul de comunicaţie activ pe care îl foloseştestaţia la un moment dat;

NR_RACKURI - este indicat numărul total de rack-uri pe care îlsupraveghează sistemul de management în cadrul unei staţii;

NR_RACKURI_DIST - reprezintă numărul total de rack-uri distante (dinstaţiile învecinate) care pot fi administrate de sistemul de management;

ADR_PROTOCOL - prin acest câmp se transmite adresa de identificarepe un canal a unei staţii;

ECA_INSTALAT - indică sistemului de management dacă staţiarespectivă este deservită de propriul agent de management (ECA – Echipamentde Colectare a Alarmelor) sau este administrată de la distanţă de la o staţievecină;

ID_DIST_ST - indică pentru staţiile ce nu sunt dotate cu ECA care esteidentificatorul staţiei la care este conectată din punct de vedere almanagementului;

NR_RACK_CON_DIST - acest câmp este asociat, de asemenea, uneistaţii neechipate cu ECA şi indică numărul rack-ului din staţia vecină la careeste conectat agentul de management.

Tabela de UNITĂŢI

Structura tabelei de UNITĂŢI este prezentată în tab. 4.2.

149

Tab. 4.1. Structura tabelei de STAŢII



Nr. crt. CÂMP TIP CÂMP1. ID_UNIT integer 2. ID_STAŢIE integer 3. NO_RACK integer 4. NO_BLOCK integer 5. NO_UNIT text

6. ID_TIP integer 7. FLUX text8. OBSERVAŢII text

Semnificaţia câmpurilor folosite în tabela de UNITĂŢI este următoarea: ID_UNIT - este câmpul de identificare a unităţii (sau cartelei)

funcţionale din echipamentul de comunicaţii; ID_STAŢIE - identifică staţia căreia îi aparţine unitatea respectivă; NO_RACK - acest câmp specifică numărul rack-ului căruia îi aparţine

unitatea respectivă; NO_BLOCK - acest câmp identifică blocul din rack-ul NO_RACK căruia

îi aparţine unitatea respectivă; NO_UNIT - acest câmp indică poziţia pe care se află unitatea

funcţională; ID_TIP - acest câmp indică tipul cartelei funcţionale; FLUX - indică fluxul de ieşire asignat la cartela curentă; OBSERVAŢII - în acest câmp pot fi făcute observaţii de către

operatorul de la consolă, relative la funcţionalitatea unităţii respective.

Tabela de TIPURI

Structura tabelei de TIPURI este prezentată în tab. 4.3.

Nr. crt. CÂMP TIP CÂMP1. ID_TIP integer 2. TIP text3. DESCRIERE text

Semnificaţia câmpurilor folosite în tabela de TIPURI este următoarea: ID_TIP - prin acest câmp este identificat tipul unei cartele funcţionale

din echipamentul de transmisiuni sau al unui obiect din structura sistemului demanagement (ECA, canal de transmisuni, port ECA etc.);

TIP - acest câmp oferă o informaţie tip text despre tipul unităţii curenteşi este util atunci când se doreşte afişarea la consolă a unor informaţii în clar despre unitatea respectivă;

DESCRIERE - în acest câmp pot fi inserate detalii suplimentarereferitoare la tipul unităţilor sau cartelelor respective.

Tabela de CANALE

Structura tabelei de CANALE este prezentată în tab. 4.4.150

Tab. 4.2. Structura tabelei de UNITĂŢI

Tab. 4.3. Structura tabelei de TIPURI



Nr. crt. CÂMP TIP CÂMP1. ID_CANAL integer 2. COM_PORT text3. INSTALAT integer

Semnificaţia câmpurilor folosite în tabela de CANALE este următoarea: ID_CANAL - acest câmp conţine informaţia referitoare la canalul pe

care este legată o staţie şi este în legătură cu tabela de STAŢII; COM_PORT - acest câmp conţine adresa portului de comunicaţie

folosit pentru sistemul de management; INSTALAT - acest câmp indică faptul dacă un canal identificat prin

ID_CANAL este instalat sau nu.

Tabela de CODURI_ALARMĂ

Structura tabelei de CODURI_ALARMĂ este prezentată în tab. 4.5.

Nr. crt. CÂMP TIP CÂMP1. ID_COD_ALARMĂ integer 2. COD_ALARMĂ text3. DESCRIERE_ALARMĂ text

Semnificaţia câmpurilor folosite în tabela de CODURI_ALARMĂ esteurmătoarea:

ID_COD_ALARMĂ - acest câmp indică ce tip de alarmă a apărut pe oanumită cartelă funcţională; COD_ALARMĂ - acest câmp conţine informaţia despre alarmă

nedecodificată, aşa cum a fost ea recepţionată de la echipament; DESCRIERE_ALARMĂ - acest câmp poate conţine informaţii

descriptive despre tipul de alarmă apărută şi poate fi afişat pe consola operator la cererea managerului.

Tabela de ALARME

Structura tabelei de ALARME este prezentată în tab. 4.6.

Nr. crt. CÂMP TIP CÂMP1. ID_ALARMĂ integer 2. ID_STAŢIE integer 3. ID_UNIT integer 4. ID_COD_ALARMĂ integer 5. APARIŢIE datetime6. DISPARIŢIE datetime7. DURATĂ long integer 8. READED integer 9. NO_RACK integer

151

Tab. 4.4. Structura tabelei de CANALE

Tab. 4.5. Structura tabelei de CODURI_ALARMĂ

Tab. 4.6. Structura tabelei de STAŢII



Semnificaţia câmpurilor folosite în cadrul tabelei de ALARME esteurmătoarea:

ID_ALARMĂ - acest câmp indică apariţia unei noi alarme, care va fi

apoi caracterizată de celelalte mărimi din tabel; ID_STAŢIE - indică staţia unde a apărut alarma identificată de

ID_ALARMĂ; ID_UNIT - acest câmp indică unitatea pe care a fost detectată noua

alarmă; ID_COD_ALARMĂ - acest câmp conţine identificatorul tipului de alarmă

apărută; APARIŢIE - acest câmp conţine data şi ora exactă la care a fost

înştiinţat serverul despre apariţia noii alarme; DISPARIŢIE - acest câmp conţine data şi ora exactă când a dispărut

alarma; DURATĂ - în acest câmp este stocată, de fapt, diferenţa dintre valorile

existente în câmpul dispariţie şi câmpul apariţie şi reprezintă durata de timp încare alarma a fost activă;

READED - acest câmp indică programului de descărcare a alarmelor din baza de date faptul că alarma respectivă a mai fost sau descărcată;

NO_RACK - acest câmp specifică poziţia rack-ului în care este situatăunitatea aflată în alarmă.

Tabela de FUNC_SPEC

Structura tabelei de FUNC_SPEC este prezentată în tab. 4.7.Nr. crt. CÂMP TIP CÂMP

1. ID integer 2. ID_UNIT integer 3. DATA_ORA_MAS datetime4. ULTIM_MAS integer 5. BER float6. EB float7. EFS float8. ES float9. SES float

10. DM float

Semnificaţia câmpurilor folosite în cadrul tabelei de ALARME esteurmătoarea:

ID - este indexul înregistrărilor din tabelă; ID_UNIT - acest câmp conţine identificatorul unităţii de pe care s-au citit

valorile mărimilor măsurate (BER, EFS, etc.); DATA_ORA_MAS - acest câmp conţine data şi ora când au fost

efectuate măsurătorile de calitate ce sunt înscrise în tabel;

152

Tab. 4.7. Structura tabelei de FUNC_SPEC



ULTIM_MAS - acest câmp indică faptul dacă măsurătorile au fostactualizate sau nu;

BER, EB, EFS, ES, SES, DM - aceste câmpuri conţin valorilemăsurătorilor de calitate efectuate.

Tabela de UTILIZATORI

Structura tabelei de UTILIZATORI este prezentată în tab. 4.8.Semnificaţia câmpurilor folosite în cadrul tabelei de ALARME este

următoarea: USER_NAME - acest câmp conţine numele utilizatorilor care au acces

la resursele sistemului de management; FLAG_ALARME - prin intermediul acestui flag programul PCA

comunică programului PPA că a apărut/dispărut o alarmă în echipamentul detransmisiuni;

ID_MPT - acest câmp conţine identificatorul MPT-ului curent, cel de pecare se citesc alarme sau se descarcă configuraţii pe echipament;

CMD_MPT - prin intermediul acestui câmp programul PPA transmitecomenzi spre echipamentele aflate în subordine;

ECRAN_MPT - acest câmp conţine informaţiile pe care programul PCAle transmite spre ecranul MPT-ului virtual;

REQUEST_WKS şi ANSWER_WKS - aceste două câmpuri conţin, defapt, primitivele necesare comunicaţiei între server şi staţiile de lucru distante;

Nr. crt. CÂMP TIP CÂMP1. USER_NAME text

2. FLAG_ALARME integer 3. ID_MPT integer 4. CMD_MPT text5. ECRAN_MPT text6. REQUEST_WKS text7. ANSWER_WKS text8. INTERDICTIE integer

INTERDICŢIE - prin intermediul acestui câmp programul PCA interzice

accesul altui utilizator la un rack pe care tocmai a fost detectată o alarmă,lăsând astfel timp rezolvării acestei probleme.

4.2.3 Arhitectura sistemului de management

Implementarea funcţiilor de management care au fost stabilite dreptobiectiv a fost realizată prin intermediul unui sistem de management complex,bazat pe tehnologia client-server şi care este compus dintr-o unitate centrală demanagement (PCS – Punct Central de Supraveghere) şi un număr de agenţilocali de management (ECA – Echipament de Colectare a Alarmelor) (fig. 4.12).

153

Tab. 4.8. Structura tabelei de UTILIZATORI



Unitatea centrală de management a fost instalată în Bucureşti, iar unnumăr de 7 agenţi de management au fost instalaţi în ţară, conform dispuneriidin fig. 4.11. După cum s-a putut observa şi din definirea bazei de date asistemului, un agent de management instalat într-o staţie poate servi şiechipamentele aflate în staţiile vecine, prin intermediul unor canale de

comunicaţii închiriate.Sistemul construit respectă specificaţiile generale ale unui sistem demanagement, aşa cum au fost ele descrise în cap. 1 şi cap. 2 (vezi fig. 2.1),fiind în acelaşi timp apropiate ca mod de abordare sistemelor de managementcu procesare distribuită, prezentate în cap. 2. După cum s-a putut observa şiprin trecerea în revistă a principalelor mărimi care sunt stocate în baza de datea sistemului (tab. 4.1 ÷ tab. 4.8), acest sistem corespunde specificaţiilor unuisistem de management al SDH (cap. 4.1).

ECA este realizată pe baza unei structuri hardware dezvoltată în jurulmicrocontrolerului 87C552. Folosindu-se de capacităţile de achiziţie şi de calculale microsistemului, ECA monitorizează, în principal, un număr de până la 6entităţi funcţionale distincte, comunicaţia cu acestea realizându-se pe liniiseriale, asincrone, cu viteza de 1200 bps, respectându-se standardul electricV.28 şi standardul funcţional RS 232.

Fiecare din aceste unităţi funcţionale distincte este prevăzută, în modsuplimentar, cu un contact static, flotant, prin închiderea acestuia,semnalizându-se dispozitivului ECA existenţa unei alarme funcţionale. Înmomentul recepţionării semnalului de alarmă, ECA se conectează automat lasistemul respectiv şi pe baza unui dialog interactiv, de tip client-server, citeştestarea funcţională a echipamentului, determinând astfel tipul alarmei.

Odată obţinute informaţiile complete referitoare la starea echipamentului,

acestea sunt prelucrate în cadrul ECA, formatate şi apoi transmise, prinmodem, echipamentului central de supraveghere, PCS-ul.

154

GALAŢI

SASCUT

ADJUD

FOCŞANI

BRĂILA

ÎNSURĂŢEI

BACĂU

ŢĂNDĂREI

Staţie de comutaţie centrală

Staţie regenerator

Staţie intermediară

Staţie terminală

Fibră optică de 140 Mb/s

Legend ă

Staţie prevăzută cu agent demanagement

Canal digital de management

Staţie prevăzută cu agent demanagement şi cu manager dereţea



155

SLOBOZIA

AFUMAŢI

URZICENI CĂZĂNEŞTI

FETEŞTI

CERNAVODĂ

MEDGIDIA

CONSTANŢABUCUREŞTI

Fig. 4.11. Localizarea agenţilor de management în cadrul reţelei



7

PCS(platformă Windows NT)

Interfaţă multiport serialăasincronă

ECA 1(platformă microcontroller

8x552)Porturi seriale asincrone

V = 1200 bps

Interfaţă serialăasincronă

v = 9600 bps


v = 9600 bps

Modem asincronv = 9600 b s

Ramă

Porturi seriale asincrone v = 1200 bps




ECA 8(platformă microcontroller

8x552)Porturi seriale asincrone

V = 1200 bps


v = 9600 bps


v = 9600 bps

Ramă

Porturi seriale asincrone v = 1200 bps

. . . . . . .

1 . . . 9

1 2 . . . 6 1 2 . . . 6

Interfaţă

V.24

InterfaţăV.24

InterfaţăV.24

DispozitivDiagnoză

InterfaţăV.24

DispozitivDiagnoză

Fig. 4.12. Schema bloc a sistemului de management PCS-ECA

156



Fig. 4.14. Schema bloc a unităţii centrale a ECA

INT RS232

IO - 2

PCS

MODEM

Sursă dealiment

A0

A1

A2

…

A5 S1

S2

S3

S4 …

S8

INTRS 232

A B C E R

Adrese MUX Port serial

Portintrări

Port ieşiri

Sistem cu micro-controller PC

INT RS232 INT RS232 INT RS232 INT RS232 INT RS232

IO - 3 IO - 4 IO - 5 IO - 7

RAMA 1 RAMA 2 RAMA 3 RAMA 4 …… RAMA 6

+ 5 V

GND

+5 V GND

+ 48 V -

R1 R2 R3 R4 … R8

PORT TESTARE

MULTIPLEXOR DIGITAL

A1 A6A3 A4A2

I.A.C.

S.A.U.C.

Fig. 4.13. Schema bloc a echipamentului de colectare a alarmelor (ECA)

E R

87C552RAM (32kB )8000H ÷ 0FFFFH

EPROM (32kB)0000H ÷ 7FFFH

Portintrări

A0A1A2…

A5 Busul de date BD0÷ 7Portieşiri

S1S2S3S4…S8BD0÷ 7 BD0÷ 7BD0÷ 7BD0÷ 7 Busul de adrese BA0÷ 7 BA0÷ 7BA0÷ 7 Busul de controlABC

E R

E R E

INT. RS 232 R

Port TEST157



SpreICA

Fig. 5.11 Schema bloc a unităţii centrale a ECA

158



La rândul său, PCS-ul poate interoga ECA privind starea funcţională aunui anumit echipament subordonat acestuia. La primirea acestei comenzi,ECA începe un dialog cu echipamentul respectiv, culege informaţiile cerute, leformatează, iar în final le transmite PCS-ului.

Există şi un al treilea mod de lucru pentru ECA şi anume configurarea şi

setarea echipamentului subordonat pe baza comenzilor primite de la managerulsistemului.Operaţiile de diagnoză şi mentenanţă ale ECA pot fi realizate fie de la

distanţă, prin intermediul unei linii închiriate, utilizându-se modemul ataşat, de laPCS, fie local, de la un laptop, pentru aceasta ehipamentul fiind prevăzut, înmod suplimentar, cu un port de acces. Această ieşire poate fi conectată serial,asincron, cu viteza de 9600 bps la un calculator pentru efectuarea diagnozeimodulului.

4.2.4 Structura hardware a ECA

Echipamentul este constituit din trei blocuri funcţionale distincte (vezi fig.4.13):

S.A. – Sursa de Alimentare; U.C. – Unitatea Centrală; I.A.C. – Interfaţa de Achiziţie şi Control.

Vom descrie, în continuare, pe scurt, compoziţia celor trei blocuri funcţionale.

Sursa de Alimentare (SA)

Este o sursă de alimentare realizată în comutaţie, care trebuie săfurnizeze, pornind de la tensiunea de – 48 V la care este conectată, o tensiuneflotantă de +5V, la un curent nominal 150 mA. Este prevăzută cu protecţie lasuprasarcină de curent, la un curent de aproximativ 500 mA decuplând automatmodulele care se alimentează de la ea.

Sursa de alimentare destinată ECA, este un convertor DC-DC, încomutaţie, care transformă tensiunea continuă de 48 V (20V ÷ 80V) dealimentare a ramelor din oficiu PTT, într-o tensiune continuă izolată şistabilizată de 5 V.

Unitatea Centrală (UC)

Este o structură de microcalculator (schema bloc din fig. 4.14), construităpe baza microcontrolerului 87C552, fiind echipată cu o memorie RAM de 32 Kbşi o memorie EPROM de 32 Kb.

Frecvenţa de lucru a microsistemului este de 15 MHz, obţinută de lacristalul de cuarţ de 15 MHz ataşat microcontrolerului.

Achiziţia datelor de la IAC se realizează cu ajutorul unui bloc decomunicaţie serială, pe trei fire (T-transmisie, R-recepţie şi M-masă),comunicaţia realizându-se asincron, cu viteza de 1200 bps, nivelele electricefiind compatibile TTL. Comanda IAC, pentru selecţia canalului de comunicaţiece se doreşte a fi stabilit, se realizează prin intermediul a trei fire, notate pe

figura 4.14 cu A, B şi respectiv C. Citirea stărilor de alarmă de la echipamente159



se face prin intermediul a până la 6 intrări distincte, cu nivele electrice TTL,notate cu A0÷ 5. Pentru a semnaliza optic exterior direcţia pe care este angajatăcomunicaţia la un moment dat, UC-ul este prevăzut cu 8 ieşiri distincte, notatecu S1÷ 8, ieşiri la care se pot ataşa direct până la 8 LED-uri.

Pentru diagnoza echipamentului, la modulul UC este ataşat un port

serial, prevăzut cu o interfaţa electrică RS 232, la care poate fi conectat uncalculator personal sau un terminal compatibil VT100.

Această unitate asigură prin intermediul IAC controlul echipamentelor terminale optice, precum şi conectarea acestora la sistem.

Microcontroller-ul în jurul căruia este dezvoltată unitatea de comandăare în principal următoarele capabilităţi:

unitate de procesare pe 8 biţi, care în cazul unui ceas extern de 15MHz are o putere de 0.6 Mips;

două timere autoîncărcabile pe 8 sau 16 biţi; 8 convertoare A/D, multiplexate, pe 10 biţi, cu timpul de achiziţie de 50

µ S; 4 porturi bidirecţionale, de câte 8 biţi fiecare; port serial asincron, UART, programabil până la o viteză de 19200 bps; port serial sincron, I2C, cu viteza de până la 100 Kbps.

Microsistemul este prevăzut cu 64 Kb memorie, din care 32 Kb suntmemorie EPROM (necesare păstrării aplicaţiilor), în această configuraţie fiindplasaţi între adresele 0H ÷ 7FFFH şi 32 Kb memorie RAM, poziţionaţi întreadresele de memorie 8000H ÷ 0FFFFH. În memoria RAM pot fi încărcate şirulate programe, astfel că sistemul permite şi rularea unor variante îmbunătăţiteale software-ului, fără vreo modificare hardware.

Sistemul are un număr de porturi compatibile din punct de vedere electric

TTL, orientate spre funcţiile de achiziţie şi comandă specificate. Porturile A0 ÷

A5 sunt 6 porturi de intrare, conectate prin intermediul IAC la contactele flotantede alarmă situate pe rack-urile ce trebuiesc monitorizate. Închiderea unuia dinaceste contacte, în cazul apariţiei unei alarme la rack-ul respectiv, conduce laapariţia unui “zero” electric la intrarea portului A i respectiv, sistemul fiind astfelanunţat de alarma respectivă.

Prin cele trei porturi de ieşire (notate A, B şi C) microsistemul comandăselecţia unuia din cele 6 canale de achiziţie respective.

Observaţie: Actuala configuraţie hardware permite ca fără modificărimajore sistemul să poată fi extins pentru achiziţionarea a până la 255 de canale

distincte.Porturile de ieşire S1÷ S8 comandă aprinderea sau stingerea a 8 LED-uri,indicând astfel la care canal este conectat sistemul în momentul respectiv.

Interfaţa de Achiziţie şi Control (IAC)

Prin intermediul acestei interfeţe UC-ul preia informaţii şi transmitecomenzi către echipamentele aflate în subordine. Nivelele electrice suntadaptate în ambele direcţii de către IAC, aceasta făcând translatarea de lanivele de ± 12V specifice echipamentelor la nivele de 0/5 V ale UC-ului.

160



De asemenea, prin intermediul acestui modul, se realizează ieşirea spremodem, pentru conectarea la unitatea centrală de management, PCS, prin linietelefonică închiriată.

Deci, IAC asigură legătura logică între UC şi echipamentele detransmisiuni pe suport optic aflate sub supraveghere, permiţând transferul

bidirecţional de informaţii între PCS şi echipamentele terminale optice, astfelcă: obiectele administrate pot transmite spre sistem stări de alarmă sau

informaţii privind starea lor funcţională; de la sistemul de management pot fi transmise spre agenţi informaţii

necesare configurării acestora sau pot fi comandate anumite teste funcţionale.

4.2.5 Descrierea funcţională a ECA

Caracteristici generale

Rolul ECA este de a asigura interfaţa între PCS şi echipamentele ceurmează a fi monitorizate şi controlate. Interogarea echipamentelor serealizează în două situaţii distincte, astfel:

atunci când PCS-ul o solicită în mod expres pentru a afla stareaacestora sau pentru a o modifica, prin pornirea unui program de “terminalvirtual” prin care operatorul aflat la punctul central poate modifica, pe baza unuimeniu interactiv, setarea parametrilor echipamentelor;

în cazul în care se detectează o stare de alarmă la unul din terminale,prin intermediul semnalelor A0÷ 5, moment în care ECA începe interogareaechipamentului care a semnalizat o stare de proastă funcţionare. Informaţiile

obţinute de la echipament sunt transferate, prin intermediul modemului, sprePCS, atunci când acesta ajunge cu “apelarea” la ECA-ul corespunzător.Comunicaţia cu PCS se realizează pe canal închiriat, prin intermediul

unui modem, cu o viteză de transfer de până la 9600 bps, în funcţie de calitateacanalului respectiv în momentul realizării transferului.

Datorită importanţei transferului corect al datelor, acesta este realizat pebaza unui protocol de comunicaţie protejat la erori ce pot atinge pragul critic de10-4. Protocolul este de tip detecţie şi corecţie a erorilor prin retransmisie,retransmisia efectându-se automat când nu s-a primit confirmarea la blocultransmis anterior sau la cererea expresă a corespondentului. Am construit acestprotocol bazându-mă de rezultatele obţinute cu protocolul de comunicaţie pe

canal comun, prezentat în detaliu în cap. 3.

Posibilităţi de diagnoză a ECA

Au fost implementate funcţii de management specifice ariei funcţionale amanagementului defectărilor (cap. 1), în particular funcţii de diagnosticare.

Diagnosticarea ECA este organizată pe trei nivele ierarhice, în funcţie deprofunzimea testelor realizate şi de localizarea acestora:

nivel intern: aparatul efectuează atât la pornire, cât şi în timpulfuncţionării, autotestarea principalelor blocuri funcţionale, iar în cazul detectăriide erori, acestea sunt semnalate PCS-ului prin intermediul modemului, urmatede restartarea automată a ECA;

161



nivel local: poate fi comandată efectuarea testelor complete aleaparatului de la un calculator personal sau un terminal compatibil VT100conectate la portul local de acces;

nivel distant: testarea echipamentului poate fi comandată, de ladistanţă, de către PCS.

Efectuarea operaţiilor de diagnoză poate fi permisă, opţional, în modselectiv, numai operatorilor avizaţi, selecţia acestora fiind realizată prin parolede acces.

Controlul şi monitorizarea sistemului

Controlul şi monitorizarea aparaturii de transmisuni pe suport optic serealizează, prin intermediul ECA, de la un Punct Central de Supraveghere(PCS). Dialogul între PCS şi ECA este de tip interogare-răspuns, fiindstructurat ierarhic pe modelul CLIENT-SERVER (descris în cap.2). PCS-ul joacă rolul de client care cere server-ului (ECA în acest caz) efectuarea unor anumite servicii specifice managementului sistemelor de telecomunicaţii(configurări de echipamente, detectarea defectărilor, monitorizareaperformanţelor acestora, etc.)

Identificarea echipamentelor accesate se realizează pe baze topologice, în funcţie de portul fizic al PCS-ului la care acestea sunt conectate.

Din punct de vedere funcţional, în fig. 4.15 sunt reprezentate principaleleblocuri aflate între operatorul uman aflat la consola PCS şi terminalul detransmisiuni care este monitorizat.

Aceste blocuri funcţionale sunt astfel constituite încât urmăresc structuralogică a desfăşurării proceselor de management.

162

MApl

MBD

MIfC MCMIfC

PCS

ECA

Fig. 4.15. Schema blocurilor funcţionale ce deservesc comunicaţia PCS-ECA

UTO

Legendă :

MApl – Modul Aplicaţie;MBD – Modul Bază de Date;MIfC – Modul Inter f aţă de Comunicaţie;MCM – Modul Control şi Monitorizare;UTO – Unitate Terminală Optică.



Operatorul uman, aflat la consola PCS, lansează o cerere către sistem.Modulul de aplicaţie interpretează această cerere şi apelează baza de datepentru a culege datele necesare. Acest modul preia apoi cererea,individualizează abonatul căruia îi este adresată şi o transmite în formatulnecesar către modulul interfaţă de comunicaţie. MIfC este “transparent” faţă de

obiectul cererii, rolul său fiind doar de a transmite neeronată cererea la modululcorespunzător, MIfC, din ECA, căruia îi este adresată. MIfC din ECA preiamesajul, îl decodifică şi îl transmite mai departe către modulul de control şimonitorizare. Acesta interpretează cererea şi interoghează la rândul săuunitatea terminală optică. Răspunsul obţinut de la aceasta parcurge tot circuitul în sens invers.

Protocolul de comunicaţie între PCS şi ECA

Între MIfC din compunerea PCS şi MIfC din ECA se poate face unschimb de informaţii, bidirecţional, pe baza unui protocol de comunicaţie, înmod “transparent”.

Protocolul pe care l-am realizat este de tip “legătură de date”,asemănător protcolului descris în capitolul 3, diferenţa fiind că în acest caz s-apreferat un protocol de comunicaţie asincron, adaptat principalelor cerinţe aleacestor tipuri de legături:

nivel mediu de erori pe linie ≈ 10 -4; capacitate mică a canalelor de transmisie (9600 bps); autenticitate mare cerută pentru informaţie. Între cele două noduri terminale, datele vor circula sub formă de cadre de

comandă, cadre de informaţie şi cadre de supraveghere (fig. 4.16).

În fig. 4.17 sunt prezentate în mod detaliat detailat toate tipurile de cadreutilizate în cadrul protocolului de comunicaţii, precum şi componenţa acestora.

163

Fig. 4.16. Tipuri de cadre specifice protocolului de comunicaţie ECA - PCS

Flag1 AlarmeCâmp decontrol

erori

ComandăECA

Flag2

Cadru de comandă

Flag3 InformaţieCâmp decontrol

eroriFlag4

Cadru de informaţie

Flag1 AlarmeCâmp decontrol

eroriFlag2

Cadru de supraveghere



Delimitarea cadrelor schimbate între ECA şi PCS se face prin intermediulindicatorilor de început şi sfârşit cadru F1 şi F2. Fiecare cadru conţine un câmpde control al erorilor, construit prin sumarea orizontală modulo 128 a tuturor octeţilor din cadru, în afara celor de control.

Protocolul construit permite o verificare complexă a bunei funcţionări a

legăturii, etapele verificării fiind următoarele:1. se verifică corecta recepţionare a indicatorilor de început şi de sfârşit

F1 şi F2;2. se verifică dacă suma de control calculată la recepţie este identică cu

cea care a fost recepţionată;3. se verifică că întotdeauna al doilea câmp al unui cadru de control este

“a”;4. se verifică apoi sintactic cadrul, deci dacă respectiva comandă face

parte din setul de comenzi acceptate de ECA în acea etapă a programului;5. se verifică timpul între transmisiile a două caractere succesive, care nu

trebuie să fie mai mare de 5 secunde în general.Fiecare din tipurile de cadre enumerate mai sus au un rol specific în

comunicaţia dintre ECA şi PCS: cadrele de comandă sunt transmise de la PCS la ECA, iar ca rezultat al

acestora ECA poate răspunde tot cu cadre de comandă sau cu cadre deinformaţie în funcţie de destinatarul comenzii. Pentru comenzi care îi suntadresate, ECA răspunde tot cu cadre de comandă, iar pentru comenzi care suntadresate rack-ului răspunde numai cu cadre de informaţie;

cadrele de informaţie sunt transmise numai de la ECA spre PCS şiconţin răspunsul pe care rack-ul îl întoarce la primirea unei comenzi de lautilizator;

cadrele de supraveghere se schimbă între ECA şi PCS numai lainiţiativa PCS şi au rolul de suport pentru întreţinerea funcţionalităţii liniei.O sesiune de lucru ECA – PCS este alcătuită din următoarele etape:1. iniţierea legăturii;2. supravegherea calităţii legăturii;3. transmiterea informaţiilor utile;4. închiderea legăturii.

Responsabil pentru supravegherea desfăşurării corecte a acestor etapeeste unitatea de management a sistemului, PCS-ul.

Verificarea permanentă a calităţii legăturii este realizată prin transmitereaperiodică a unor “cadre de supraveghere”, în paralel cu efectuarea unui calcul

statistic pentru determinarea aproximativă a ratei de erori existentă la unmoment dat pe linia de comunicaţii.Informaţia este transmisă în pachete şi nu se trece la următorul pachet

până când nu se primeşte confirmarea recepţionării corecte a pachetuluianaterior. Acest mod de transmisie este avantajat de debitul scăzut al datelor ce se vehiculează pe acest canal, combinat cu o rată de erori medie a acestuia.

Programele sunt scrise în limbajul C pentru modulul MIfC localizat peECA.

164



F1 a c NrCanal RegStAl r NrRec1 NrRec2 CTRL F2

F1 a p NrPort RegStAl

CTRL F2

F1 a s RegStP RegStAl

p NrPort CTRL F2

F3 Informaţie CTRL F4

F1 a p NrPort RegStAl

CTRL F2

F1 a c NrCanal RegStAl

CTRL F2

F1 a c NrPortT RegStAl

t e/g CTRL F2

F1 a c NrRec1

RegStAl

NrRec2 Informaţie CTRL F2

a) Formatul cadrului ce conţine informaţia recepţionată de către ECA şi transmisă spre PCS

c) Formatul cadrului emis de ECA la selecţia distantă a unui port

b) Formatul cadrului ce conţine starea alarmelor la porturile ECA

e) Formatul cadrului ce conţine rezultatul testării distante a unui port al ECA

f) Formatul cadrului de retransmisie a datelor spre PCS

g) Formatul cadrului ce conţine informaţia privitoare la starea funcţională a porturilor ECA

d) Formatul cadrului emis de ECA la selectarea unui port ca port activ

165



Legendă :

F1 indicator început cadru;F2 indicator sfârşit cadru;F3 indicator început cadru auxiliar;F4 indicator sfârşit cadru auxiliar;a caracter ce precede octetul de stare al alarmelor;RegStAl registru stare alarme la ECA;c caracter ce precede numărul canalului ECA de la care s-a făcut recepţia;NrCanal numărul canalului de la care s-a făcut recepţia;r caracter ce precede numărul real al caracterelor recepţionate

de către ECA de la echipamentele deservite;NrRec1 digitul zecilor din numărul caracterelor recepţionate;NrRec2 digitul unităţilor din numărul caracterelor recepţionate;CTRL octet de control al cadrului transmis;Informaţia informaţia efectivă recepţionată de ECA de la echipamentele

deservite şi retransmisă spre PCS;p caracter ce precede numărul portului activ în acel moment pe

ECA;NrPort numărul portului activ pe ECA;NrPortT numărul portului testat distant pe ECA;e caracter ce indică incorecta funcţionare a portului testat;g caracter ce indică corecta funcţionare a portului testat;s caracter ce precede registrul de stare al porturilor;RegStP registru stare porturi;

Trebuie remarcat că pe echipamentul PCS, modulul MIfC este, de fapt,divizat în două componente: în modulul propriu-zis de comunicaţie (MC) şi unmodul supervizor de reţea (MSR), ca în fig. 4.18.

MSR

Legătură dedate

Reţea

MCNivel 2

OSI

Nivel 3 OSI

MifCdelaPC

S

Fig. 4.18. Organizarea funcţională a MIfC de pe PCS

Fig. 4.17. Formatul cadrelor ce pot fi transmise de la ECA spre PCS

166



Funcţionarea programului de pe ECA

Programul de pe ECA este alcătuit dintr-un set de programe, fiecarespecializat pe realizarea unor anumite funcţiuni:

programul principal de supervizare: este programul care asigură

iniţializarea ECA la pornire, integrarea funcţională a tuturor programelor componente şi cel care decide restartarea ECA în cazul unor erori mari deprocesare raportate de programul de auto-verificare al ECA (fig. 4.23);

programul de comunicaţie cu PCS-ul : este programul ce asigurăimplementarea protocolului de comunicaţie între ECA şi PCS, asigurând un fluxde date transparent, fără erori spre ECA (fig. 4.22);

programul de comunicaţie cu ramele: este responsabil cu transmisiaşi recepţia corectă spre/dinspre rame a comenzilor şi informaţiilor primite de laPCS (fig. 4.20);

programul de supraveghere şi procesare al alarmelor existente perame: monitorizează permanent starea intrărilor de alarme dinspre ECA, avândun algoritm propriu de luare a deciziei existenţei unei alarme la o ramă (fig.4.19);

interpretorul de comenzi : decodifică comenzile primite de la PCS şi cuavizul programului de supervizare execută aceste comenzi;

programul de verificare funcţională a porturilor ECA: la iniţiativainterpretorului de comenzi poate iniţia şi desfăşura un program de verificarefuncţională parţială sau totală a porturilor ECA, prin transmiterea unei secvenţede testare spre acestea şi interpretare a datelor recepţionate ca rezultat altestului (fig. 4.21);

programul de verificare a bunei funcţionări a ECA: urmăreşte

permanent două aspecte principale ale unei bune funcţionări a ECA: funcţionarea principalelor blocuri hardware – memorie EPROM,RAM, logica de comandă, porturi I/O, etc;

funcţionarea globală a software-ului, prin efectuarea unor minicicluride testare din 50 în 50 de ms, în cazul blocării programului în această etapătransmite programului de supervizare cererea de restartare a ECA.

Metode de testare a ECA

ECA este un echipament complex, testarea acestuia putându-se executaatât automat la pornire, cât şi manual , prin intervenţia unui operator extern.

Testarea manuală se poate realiza de către trei tipuri distincte de operatori:• local , prin intermediul unui buton de test (TEST);• local , prin intermediul unui terminal ASCII conectat la portul de diagnoză;• distant , de la PCS, prin intermediul cablului conectat la mufa notată PCS.

Subrutinele de testare permit realizarea unor teste complexe, atât asupramodulelor interne ale echipamentului, cât şi asupra conexiunilor externe aleacestuia.

Initializare subprocesare

alarme167



Formez masca decitire a alarmelor

Citesc stareaalarmelor de la

porturi

VerificRegStAlVechi ≠

RegStAlNoi

Întârziere 20 ms

Recitesc stareaalarmelor de la

porturi

VerificRegStAlVechi ≠

RegStAlNoi & dacă celedouă citiri sunt identice

Reactualizez

RegStAl

Afişezmodificarile laDGZ şi PCS

Sfârşit procesarealarme

NU

NU DA

Fig. 4.19. Organigrama funcţională a subrutinei de procesare a alarmelor

Iniţializare subcomunicaţie

ramă168



Temporizare 30 ms

Transmit un caracter spre PCS;Incrementez contorul transmisiilor.

Temporizare pre-programată

Terminattransmisie ?

Temporizare 30 ms

Recepţionez un caracter de la ramă;Incrementez contorul caracterelor

recepţionate.

Timp scurs ≤ 5 sec.

Contoar car.Rec. ≤ 80

Descarc datelerecepţionate în buffer-ul de

recepţie ramă

Sfârşit subrutină de comunicaţiecu rama

NUDA

DA

Fig. 4.20. Organigrama funcţională a subrutinei de comunicaţie ECA cu o ramă

Iniţializare subverificare stare

port ECA

NU

169



Citesc datele de la consolăsau distant

Intrări corecte ?

Setez portul la care

voi face testul!

Transmit şirul de test spre portul dorit

Recepţie corectă ?

Aştept 50 ms

Aştept 100 ms

Retransmit şirul de test spre portul dorit

Recepţie corectă ?

Afişează că portul funcţionează INCORECT

Afişează că portul funcţionează

CORECT

ReactualizeazăRegStP

Sfârşit subrutină verificarestare port

DANU

DANU

DANU

Fig. 4.21. Organigrama funcţională a subrutinei de verificare a funcţionalităţiiunui port de pe ECA

Iniţializare subrecepţie de la

PCS

170



Caracter nourecepţionat ?

Cadru în

curs derecepţie ?

Caracter Rec. = F1 ?

Caracter Rec. = F2 ?

Descarc car. Rec. înbuffer-ul temporar

Incrementezcontoar car.

Rec.

Contor car.Rec ≤ Max

Resetez cadrul în curs;Reiniţializez contoarele.

Calculez caracterul decontrol CTRL

Verific CTRLcorect ?

Descarc buffer-ultemporar în cel de

recepţie

Verifică datele dinpunct de vedere

sintactic şi letransferă buclei

principale

Sfârşit subrutină recepţiedate de la PCS

NU DA

DA NU

NU DA

DA

Resetez cadrul în curs;Reiniţializez contoarele.

NU DANU

Setez indicatorul cadru încurs de recepţie

NU

DA

Fig. 4.22. Organigrama funcţională a subrutinei de recepţie a ECA

Iniţializareprogram

principal ECA

Testare principalelecomponente ale ECA

Lansează subrutină verificarealarme

171



Testele interne se efectuează automat la pornire şi verifică bunafuncţionare a:

memoriei RAM interne a microcontroller-ului (128 bytes); memoria RAM externă (32 Kb); memoria ROM externă (32 Kb);

a microprocesorului pe 8 biţi inclus în microcontroller.Testele externe asigură verificarea funcţionării corecte a următoarelor componente:

blocul de selecţie a porturilor; echipamentul vizual de afişare; porturile de comunicaţie cu: terminalul de diagnoză, PCS-ul,

echipamentele de multiplexare.

Descrierea testelor:

Verifică recepţiede la PCS ?

Verifică recepţiede la consolă ?

Lansează subrutină procesaremeniu

Lansează subrutină procesarecomunicaţie cu PCS

NU DA

NU DA

Fig. 4.23. Organigrama funcţională a programului principal al ECA

172



Verificarea memoriei RAM: se efectuează o verificare complexă, prinoperaţii succesive de salvare, scriere, citire şi refacere a întregii memorii RAM,raportându-se locaţiile de memorie defecte.

Verificarea memoriei ROM: se efectuează calculul sumei de control şicompararea rezultatului acestuia cu valoarea preânscrisă la o anumită locaţie în

ROM.Verificarea blocului de selecţie a porturilor: la o comandă externă

este afişată o anumită schemă optică prestabilită, care poate fi verificată vizualde către operatorul care efectuează testul.

Verificarea porturilor de comunicaţie: presupune existenţa unuiport de conectare, exterior, pe care sunt realizate următoarele legături:

transmisia legată cu recepţia (pinul 2 legat la pinul 3) în cazul verificăriicomunicaţiei;

pinul de alarmă legat la masă (pinul 1 legat la pinul 7).Pentru verificarea comunicaţiei programul transmite la portul selectat o

secvenţă de biţi după un model cunoscut anterior, la recepţie urmărindu-seprimirea aceleiaşi secvenţe.

La verificarea alarmei, simpla introducere a conectorului special dealarme pe un port anume ar trebui să conducă la afişarea unei alarme pecanalul respectiv:

clipirea alternantă de 4 ori a LED-ului corespunzător canalului respectivşi a LED-ului asociat canalului de diagnoză, timp de 80 de ms;

afişarea la portul de diagnoză a mesajului:

********************

| Alm. nr. = 4 |

********************,

exemplu pentru cazul în care am avea alarmă pe portul cu numărul 4; afişarea aceluiaşi mesaj la portul corespunzător conexiunii cu PCS-ul;

Verificarea şi setarea modemurilor:

Modemurile acceptă mai multe tipuri de teste, cât şi reconfigurarea de ladistanţă. Pentru toate aceste tipuri de teste trebuie intrat în modul linie decomandă modem.

a. buclă locală de tip analogic

Se vor trimite spre modem caracterele “at&t1” urmate de <CR>.Modemul trebuie să răspundă cu “OK!” în cazul efectuării corecte a

comenzii şi apoi să efectueze o buclă analogică internă la ieşirea spre linie.Din acel moment orice caracter introdus de la consolă va trebui “buclat“

de către modem şi va apărea pe ecranul terminalului. Prin caracterele “at&t0”urmate de <CR> se va ieşi din modul de testare anterior.

b. buclă locală de tip digital

173



Se intră în modul de comandă prin tipărirea carcacterelor “+++”. Dupăcirca o secundă modemul local a realizat o buclă digitală. De la modemuldistant se pot trimite acum scurte mesaje care trebuie să fie reîntoarse de bucladigitală realizată local. Pentru ieşire din acest mod de testare se trimite spremodemul local setul de caractere “at&t0”, urmat de <CR>.

c. buclă distantă de tip digital

Pentru aceasta se va ieşi din legătura realizată cu corecţie de erori princomanda “atz”, care va reseta modemul de la PCS. Apoi se va încărca în acestmodem comanda “at&m4&w”, urmată de <CR>, iar la primirea răspunsului“OK!” modemul va fi resetat pentru încărcarea automată a noilor parametri princomanda “atz”. Din acest moment modemurile vor reiniţia automat o nouălegătură, în cazul acesta fără corecţie de erori. După realizarea legăturii, peecranul PCS-ului va apărea mesajul “CONNECT TO 9600”. Acum poate fiefectuat testul de buclare digitală la distanţă, trimiţându-se un set de caractere“+++” pentru trecerea în modul comandă, după care prin trimiterea setului decaractere “at&t6”, urmate de caracterul <CR> se va trece modemul distant înstarea de buclă digitală la ieşirea spre ECA. Odată efectuată buclarea ladistanţă pot fi trimise orice caractere de la consolă, acestea ajungând lamodemul distant de unde se vor reîntoarce la modemul generator, care le varedirecţiona spre ecranul terminalului PCS.

Ieşirea din acest mod de testare se va efectua tot cu ajutorul comenzii“at&t0”, urmată de caracterul <CR>.

Dialogul ECA – Utilizator

Setul de comenzi acceptat de către ECA, prin intermediul interpretoruluide comenzi, poate fi împărţit în două, în funcţie de destinatarul acestor comenzi:

comenzi destinate ECA, se caracterizează prin faptul că toate încep princaracterul “#” şi conţin numai caractere text mici;

comenzi destinate ramelor , toate acestea folosind caractere text mari şise încheie cu <CR>.

Comenzile destinate ECA pot avea până la 40 de caractere ASCIIlungime, trebuie să înceapă obligatoriu cu caracterul “#”, să conţină numai literemici sau cifre de la “0” la ”9”, iar între transmisiile a două caractere succesive nu

trebuie să fie în general o pauză mai mare de 5 secunde.Pachetul de comenzi destinat ECA este descris în continuare: “#a” determină ECA să transmită spre DGZ şi spre PCS starea

registrului de alarme:• spre DGZ se va transmite caracterul “a” urmat de octetul de

alarme la care s-a adăugat pentru formatare valoarea 48D;• spre PCS pot fi trimise două feluri de mesaje, în funcţie de

regimul de lucru: în regim demo se va transmite caracterul “a” urmat de octetul de

alarme la care s-a adăugat valoarea 48D; în regim real se va transmite un cadru cu următorul format

“F1aApPCTRLF2 ”, unde:174



- F1, indicator 1 cu valoarea 1D;- F2, indicator 2 cu valoarea 2D;- a, caracterul “a”;- A, octetul de alarme, care conţine starea alarmelor

la porturile de la 2 ÷ 7 (canalele 1 ÷ 6), asociat în ordinea C1 la b0, C2 la b1

etc. la care s-a adăugat pentru formatare valoarea 48D;- p, caracterul “p”;- P, numărul canalului selectat în ASCII, cu valori de

la 48D ÷ 55D;- CTRL, caracterul de control.

“#b” determină ECA să retransmită spre PCS bufferul datelor recepţionate în următorul format: “F1aAcNICTRLF2 ”, unde:

• F1 este indicator început cadru şi are valoarea 1D;• F2 este indicator sfârşit de cadru şi are valoarea 2D;• a, adică caracterul “a”;• A, octetul ce conţine registrul de alarme;• c, adică caracterul “c”;• N, numărul de caractere, pe doi octeţi, în format ASCII,

recepţionate de la ramă, fiind contorizate şi caracterele LF introduse de ECApentru formatare;

• I, câmp de informaţie care conţine caracterele recepţionate de laramă, la care s-au adăugat şi caracterele LF după fiecare CR recepţionat;

• CTRL, caracterul de control. “#c” urmat de o cifră de la “0” la “7” (corespunzătoare unui canal din

cele 8) are drept rezultat selectarea timp de o secundă a canalului ales, acţiune

semnalizată şi prin aprinderea LED-ului asociat canalului, în timp ce laterminalul de DGZ şi cel de la PCS se afişează caracterul ”c” urmat de numărulcanalului introdus;

“#d” , pentru setarea timpului de citire a unei rame. După introducereaacestei comenzi va fi afişat un mesaj privind valoarea acestui interval, valoarecare este măsurată în multipli de 500 de ms. Acest mesaj va fi formatat înfuncţie de regimul în care se află ECA:

• regim demo:•

********************

| Se modifica timp |

| Vechea valoare = x********************,

unde x reprezintă valoarea indicelului de multiplicare a timpului setată înacel moment;

În maxim 5 secunde trebuie introdus noul indice de multiplicare, cu valori în intervalul “1” ÷ “9”, deci se poate obţine o valoare absolută pentru acestinterval temporal între 500 ÷ 4500 ms.

Observaţie: La pornirea programului indicele de multiplicare este setat la2, deci timpul de citire a unei rame este de 1 secundă.

• regim real: va fi afişat un cadru cu următoarea alcătuire:“F1aAdTCTRLF2” , unde câmpurile componente au următoarea

175



semnificaţie: F1, indicator început de cadru, cu valoarea 1D; F2, indicator sfârşit de cadru, cu valoarea 2D; a, caracterul “a”, pregăteşte afişarea registrului de alarme; A, octetul ce conţine registrul de alarme; d, caracterul “d”, pregăteşte afişarea indicelui de multiplicare; T, indicele de multiplicare, care a fost formatat prin adăugarea

valorii 48D; CTRL, octetul de control al cadrului.

Exemplu afişare cadru : “ a8d63”. “#f” este folosit pentru setarea pauzei între transmisia a două

caractere succesive spre ramă. Pauza poate fi selectată în intervalul 0 ÷ 180ms, în multiplii de indicele de multiplicare, care este de 20 de ms. Dupăintroducerea acestei comenzi, în funcţie de regimul în care este ECA, peconsola activă va apărea următorul mesaj:

• regim demo:

********************

| Pauza intre trs. |

| Vechea valoare = 7

********************,

în cazul în care vechea valoare a indicelui de multipicare era 7, deci pauza erade 140 ms.

• regim real :va fi afişat un cadru “F1aAfFCTRLF2” , unde

F1, indicator început de cadru, cu valoarea 1D; F2, indicator sfârşit de cadru, cu valoarea 2D; a, caracterul “a”, pregăteşte afişarea registrului de alarme; A, octetul ce conţine registrul de alarme; f, caracterul “f”, pregăteşte afişarea indicelui de multiplicare; F, indicele de multiplicare, care a fost formatat prin adăugarea

valorii 48D; CTRL, octetul de control al cadrului.

Exemplu afişare cadru : “ a8f76”.

După afişarea acestui mesaj de întâmpinare ECA aşteaptă timp de 5secunde introducerea unei valori pentru indicele de multiplicare, în intervalul “0”÷ “9”. Dacă este depăşit timpul de aşteptare sau valoarea introdusă nu este înintervalul impus, programul va ignora această comandă şi va reveni în stareade aşteptare. Dacă condiţiile sunt îndeplinite corect, în funcţie de regimulselectat, pe consola activă va fi afişat următorul mesaj:

• regim demo:

********************

| Noua valoare = 6

********************,

176



în cazul în care valoarea nou introdusă este 6 pentru indicele de modulaţie.

• regim real :va fi afişat un cadru “F1aAfFCTRLF2” , unde

F1, indicator început de cadru, cu valoarea 1D; F2, indicator sfârşit de cadru, cu valoarea 2D; a, caracterul “a”, pregăteşte afişarea registrului de alarme; A, octetul ce conţine registrul de alarme; f, caracterul “f”, pregăteşte afişarea indicelui de multiplicare; F, noul indicele de multiplicare, care a fost formatat prin

adăugarea valorii 48D; CTRL, octetul de control al cadrului.

Exemplu afişare cadru : ” a8f66”

Observaţie: La pornirea programului indicele de multiplicare este setat la3, deci intervalul iniţial între transmisiile succesive a două caractere este de 60de ms.

“#g” este destinat afişării la consola PCS a registrului de stare alporturilor. Mesajul afişat este formatat într-un cadru de următoarea formă:“F1aAsRpPCTRLF2”, unde:

F1, indicator început de cadru, cu valoarea 1D; F2, indicator sfârşit de cadru, cu valoarea 2D; a, caracterul “a”, pregăteşte afişarea registrului de alarme;

A, octetul ce conţine registrul de alarme; s, caracterul “s”, pregăteşte afişarea registrului de stare alporturilor; R, registrul de stare a porturilor, care a fost formatat prin

adăugarea valorii 48D; p, caracterul “p”, pregăteşte afişarea numărului portului activ în

acel moment pe ECA; P, numărul portului selectat pe ECA, formatat prin adăugarea

valorii 48D, intervalul 48D ÷ 55D; CTRL, octetul de control al cadrului. “#l” va determina ECA, indiferent de regimul în care se află să

afişeze la consola activă în acel moment meniul disponibil, în formatul demai jos:

********************

| Meniu comenzi |

| a - citesc Al. |

| b - retransmisie|

| c - sel. port |

| d - sel. timp |

| f - sel. pauza |

| g - citesc StP. |

| l - meniu |

177



| m - regim PCS |

| n - regim DGZ |

| p - comut. port |

| r - regim real |

| t - verif. tot. |

| v - verif. port || u - regim demo. |

| x - RESET |

| y - C-da Modem |

********************.

“#m” va transfera comanda de la portul de diagnoză (DGZ) laportul de supervizare (PCS). De asemenea, va comuta modul de lucrutrecând în modul real, cu detecţie de erori. După efectuarea acesteicomenzi pe ecranul terminalului de diagnoză, ca şi pe cel de supervizareva apare mesajul:

********************

| Comanda la PCS |

********************

“#n” va transfera comanda de la portul de supervizare (PCS) laportul de diagnoză (DGZ). După efectuarea acestei comenzi pe ecranulterminalului de diagnoză, ca şi pe cel de supervizare va apare mesajul:

********************

| Comanda la DGZ |

********************

“#p” urmat de un caracter în intervalul de la “0” la “7“ are dreptrezulat selectarea unui canal de lucru real pentru restul comenzilor ce vor fitrimise de la operator spre ramă. În mod implicit este setat primul canalspre rame, canalul 1, deci portul 2. Odată introdusă această comandă, înfuncţie de modul de lucru în care se află setată ECA, pe ecranulterminalului de diagnoză, cât şi pe cel al portului de supervizare pot apareurmătoarele mesaje:

•

regim demo:********************

| CANALUL NR. = 5|

********************,

în cazul în care a fost selectat portul cu nr. 5;

• regim real :“F1aApPCTRLF2”, unde

F1, indicator început de cadru, cu valoarea 1D;

F2, indicator sfârşit de cadru, cu valoarea 2D;178



a, caracterul “a”, semnifică afişarea registrului de alarme; A, registrul de alarme la care s-a adăugat valoarea 48D; p, caracterul “p” ce pregăteşte afişarea numărului de port

selectat; P, numărul portului selectat, intervalul de afişare fiind “0” până la

“7” în ASCII sau 48D ÷ 55D; CTRL, caracterul de control, modulo 128;

Exemplu afişare în regim real: “ a8p5=”.Observaţii:

pentru protecţia la blocare se impune un interval de 5 secunde întrerecepţionarea carcaterului “p” şi recepţionarea numărului portului, iar cazuldepăşirii acestui interval, programul se întoarce automat în bucla principală;

dacă în loc de numărul portului dorit se introduce “CR”, indiferent deregim, pe ecran se afişează numărul portului curent selectat;

orice altă comandă introdusă va determina programul să o ignore şi săse apoi întoarcă în bucla principală.

“#r” are drept rezultat comutarea din regimul demonstrativ în regimulreal de lucru, cu detecţie de erori. Confirmarea schimbării modului de lucru seva face prin afişarea la consola activă a următorului mesaj:

********************

| Regim interogare|

********************

“#t” are drept rezultat efectuarea unui test global al porturilor, în ordine

crescătoare de la 0 la 7, iar apoi efectuarea aceluiaşi test în ordinedescrescătoare. Pentru fiecare test în parte vor fi afişate rezultatele ca le testeleefectuate prin comanda “v”;

“#u” are drept rezultat comutarea din regimul real de lucru în regimuldemonstrativ. Confirmarea schimbării modului de lucru se va face prin afişareala consola activă a următorului mesaj:

********************

| Regim diagnoza |

********************

“#v” urmat de un caracter de la “0” la “7” determină ECA să porneascăun program de verificare a bunei funcţionări a portului dorit. Pentru protecţie lablocare, a fost prestabilit un interval maxim de 5 secunde în care poate fiintrodusă cifra corespunzătoare valorii portului testat. În cazul în care acestprag va fi depăşit, programul se va întoarce în bucla principală, aşteptândintroducerea altei comenzi. Aceeaşi decizie va fi luată şi în cazul în carenumărul portului nu este introdus corect, în intervalul impus.

Pentru verificare va fi trimisă, spre portul selecţionat, o secvenţă decaractere prestabilite, iar la port va trebui să fie conectată o mufă de test(descrisă anterior). În cazul unei funcţionări corecte a portului respectiv va firecepţionată secvenţa de caractere trimise în perioada testării. Modul de afişare

a rezulatului testului depinde de regimul în care se află ECA în acel moment:179



• regim demo: Pe ecranul terminalului conectat la portul DGZ vaapare numărul canalului testat, urmat de caracterul “G” în cazul unei funcţionăricorecte sau de caracterul “E” în cazul unei erori. În paralel este asigurată oconfirmare vizuală pentru operator, prin intermediul LED-urilor situate pe panoulfrontal: dacă rezultatul testului este pozitiv se va aprinde timp de o secundă, în

mod continuu, LED-ul corespunzător canalului respectiv, iar în cazul uneifuncţionări incorecte se vor aprinde alternant (de 4 ori consecutiv, timp de 80ms), LED-ul asociat canalului testat şi LED-ul de DGZ sau cel de la PCS;

• regim real : spre portul PCS va fi trimis un cadru cu următorulformat: “F1aAcNtRCTRLF2” , unde câmpurile au următoarea semnificaţie:

F1, indicator de început cadru cu valoarea 1D; F2, indicator de sfârşit cadru cu valoarea 2D; a, caracterul “a”; A, octetul ce conţine registrul de alarme; c, caracterul “c”; N, octet ce conţine, în ASCII, numărul canalului care a fost

testat, cu valoare de la 48D la 55D; t, caracterul “t”, semnificând faptul că urmează afişarea

rezultatului testului; R, rezultatul testului, “e” în cazul în care testul a eşuat şi ”g”

dacă a reuşit; CTRL, caracter de control al cadrului.

Observaţie: Odată cu afişarea rezulatelor testului va fi actualizat şiregistrul cu starea porturilor, astfel că pentru test reuşit va fi setat bitulcorespunzător numărului portului (porturile sunt numerotate de la 0 la 7, la felca biţii corespunzători din registrul de stare a porturilor), iar pentru test nereuşit

va fi resetat bitul respectiv. “#x” va conduce la resetarea echipamentului ECA, fiind echivalentă cuefectuarea unui reset “la cald”. Confirmarea acceptării comenzii se va facevizual, prin afişarea la consola activă a următorului mesaj:

********************

|ECA SE RESTARTEAZA|

********************.

“#y” comandă de acces la modul de lucru linie de comandă amodemului ataşat ECA, destinată testării şi setării modemului în modul de lucru

real. Comenzile destinate ramelor pot avea până la 80 de caractere ASCIIlungime, trebuie să se termine obligatoriu cu caracterul “CR”, să conţină numailitere mari sau cifre de la “0” la ”9”.

Aceste comenzi vor fi transmise spre rame în mod transparent, inclusivcaraterul “CR”. Odată transmisă o linie de comandă spre ECA, acesta o vatransmite spre portul activ din acel moment (setat cu “#p…”), pauza dintretransmisiile a două caractere succesive fiind cea setată prin comanda “#d…”(valoarea implicită fiind de 60 de ms). Următoarea etapă este recepţionarearăspunsului de la ECA. Pentru aceasta ECA va “asculta” rama un timp egal cucel setat de utilizator prin comanda “#f..”, implicit acesta fiind de o secundă.

180



Ieşirea din modul ascultare se va face fie la expirarea timpului setat, fiela depăşirea numărului limită de caractere recepţionate, adică la recepţionareacelui de al 81lea caracter. Caracterele recepţionate vor fi formatate prinadăugarea caracterului “LF” înaintea fiecărui caracter “CR” recepţionat de laramă, urmând apoi stocarea lor într-un buffer de rezervă de unde vor putea fi

rechemate de la PCS prin comanda “#b”, descrisă în meniul de comenziaccesibile utilizatorului. Transmiterea iniţială a datelor recepţionate spre PCS seva face respectând un format anume, în funcţie de regimul de lucru în care seaflă ECA.

• regim demo: Datele vor fi precedate de un antet care va anunţade la ce port au fost recepţionate şi numărul real de caractere recepţionate dela ramă:

********************

| CANALUL NR. = 6|

| CARACT. REC.= 02|

********************g,

în exemplul de mai sus datele au fost recepţionate de la portul numărul 6, erau în număr de 2 şi acestea au fost caracterele “g” şi “CR”.

• regim real : Datele vor fi formatate într-un cadru ce va facilitadetecţia de erori la PCS şi anume: “F1aAcCrR1R2CTRLF2F3ICTRLF4”, undecâmpurile au următoarea semnificaţie:

F1, indicator început de cadru control, cu valoarea 1D; F2, indicator sfârşit de cadru control, cu valoarea 2D;

a, caracterul “a”, pregăteşte afişarea registrului de alarme; A, octetul ce conţine registrul de alarme; c, caracterul “c”, pregăşte afişarea canalului de unde au fost

recepţionate datele; C, numărul portului de la care a fost efectuată recepţia, în format

ASCII, cu valori de la 48D÷ 55D; r, caracterul “r”, pregăteşte afişarea numărului de caractere

recepţionate, pe doi octeţi; R1, cifra zecilor la număr, care a fost formatată prin adăugarea

valorii 48D; R2, cifra unităţilor la număr, care a fost formatată prin adăugarea

valorii 48D; CTRL, octetul de control al cadrului de control. F3, indicator început de cadru de informaţie, cu valoarea 3D; F4, indicator sfârşit de cadru de informaţie, cu valoarea 4D; I, câmpul de informaţie ce conţine datele recepţionate de la ramă; CTRL, octetul de control al cadrului de control.

4.3 Concluzii

În cadrul acestui capitol a fost prezentat modul de realizare amanagementului în cadrul reţelelor SDH.

181



Prima parte, folosind noţiunile şi principiile generale introduse în cap. 2,au fost descrise sistemele de tipul SDH, acestea putând fi asimilate uneistructuri particulare de sistem cu o arhitectură OSI.

Partea a doua a capitolului este dedicată prezentării contribuţiilor pe carele-am avut în realizarea unui sistem de management integrat pentru o reţea de

transmisiuni pe suport de fibră optică.Contribuţia adusă de mine la realizarea acestui sistem de management,realizat în colaborare cu INSCC, constă în următoarele:

proiectarea şi realizarea practică a echipamentului de colectare aalarmelor, ECA, în principal unitatea centrală şi interfaţa de comunicaţie cuclientul;

proiectarea protocolului de comunicaţie folosit ca suport pentru sistemulde management (pe baza realizărilor prezentate în cap. 3);

realizarea în totalitate a setului de programe rezidente pe ECA; participarea la definitivarea cerinţelor funcţionale ale bazelor de date

relaţionale de pe PCS; realizarea setului de programe ce asigură suportul de comunicaţie pentru

PCS (pentru comunicaţia cu ECA subordonate şi prin intermediul acestora cuobiectele de administrat);

proiectarea şi implementarea protocolului de comunicaţie dintre sistemulde management şi echipamentele ce trebuiau administrate;

echiparea, punerea în funcţiune şi setarea echipamentelor ECA. În continuare, sunt descrise cerinţele funcţionale generale pe baza

cărora a fost construit sistemul precum şi baza de date cu informaţii demanagement, realizată conform modelului MIB. Au fost utilizate pentrutransportul informaţiilor de management canale de date externe sistemului

(DCC), iar protocoalele de comunicaţie le-am realizat particularizând modelulfolosit pentru canalul comun de semnalizare a cărui realizare am descris-o încapitolul anterior. Sistemul de management pe care l-am realizat esteoperaţional din perioada decembrie 1999 pe tronsonul B de transmisiuni pesuport de fibră optică al RomTelecom şi funcţionează în condiţii optime, ceea cedovedeşte viabilitatea modelului de reţea de management realizată şirobusteţea protocoalelor de comunicaţii implementate.

182

managementul retelelor sdh

Documents