managementul reţelelor sdh – teorie şi implementare practică

www.cartiaz.ro – Carti si articole online gratuite de la A la Z

Managementul reţelelor SDH – teorie şi implementare 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 au fost evidenţiate sistemele de management pentru SS7 şi reţelele de management ale telecomunicaţiilor (TMN). Folosind ca bază teoretică de plecare informaţia referitoare la aceste două sisteme poate fi studiat şi cazul particular al managementului SDH.

Reţeaua SDH asigură suportul de transport pentru TMN, utilizând canalele DCC (”Data Communication Channels” – Canale de comunicaţii de date) [G.831]. Pe aceste canale, fluxul informaţiilor de management se transmite utilizând un protocol de legătură de date, LAPD [Q.921], un caz particular 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ă o reţea SDH. În continuare, va fi descris modelul de management al unei asemenea reţele.

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

SDH conţine un sistem integrat de management al reţelei, distribuit atât la nivelul echipamentelor de reţea, cât şi în puncte centrale de gestiune. Transportul informaţiilor de management între toate aceste noduri se poate face 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 SDH trebuie să aibă capacitatea de a asigura:

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

operarea automată a unei reţele deservite de un operator unic, dar ale că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 de management al reţelelor SDH pot fi enunţate prin intermediul a şase principii generale:

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

131

http://Www.cartiaz.ro/


2. capacitatea de a menţine, pentru aceste căi, a unei calităţi înalte a serviciilor, 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 în interiorul 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 utilizarea resurselor, 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 de management 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 mod esenţial de respectarea unui mod de identificare unic al acestora din urmă. Aceasta implică existenţa unui număr global unic de identificare pentru fiecare punct 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 baza cărora să poată fi determinat operatorul căruia îi aparţine nodul respectiv, cât şi reţeaua din care face parte. Setul identificatorilor punctelor de acces din cadrul unei reţele trebuie să asigure o schemă unică de identificare, independentă de

132

ADM

NM

…

MUX

NM

…

MUX

NM

…

DCS

NM

… …

afluenţi

afluenţi

conexiune fizică

Fig. 4.1. Exemplu de sistem de management al SDH

Informaţii de redundanţă încorporată

Canale auxiliare dedicate managementului de reţea



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

În cadrul unei reţele de management a SDH, funcţiile primare de management 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 şi transportul mesajelor între procesele de control diferite implicate. Ea operează cu două tipuri distincte de mesaje, specifice oricărei structuri de control ierarhizată pe nivele funcţionale (fig. 4.2):

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

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

Poate fi făcută o diferenţiere între modul de stabilire a unei noi căi între doi operatori 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 fi folosite 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 metode distincte de stabilire a unei căi.

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

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

133

Niv

el f

izic

N

ive

l sec

ţiu

ne

N

ivel

se

cţiu

ne

Niv

el c

ale

reg

en

era

re

mu

ltip

lex

are

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



Aceasta poate fi încorporată elementelor de reţea şi atunci va folosi protocoalele proprii mediului SDH [Q.784], descrise în continuare, fie va fi externă acestora şi atunci va folosi modul de adresare descris în [M.3010 şi G.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. De asemenea, dacă controlorul de procesare se află în interiorul nodului vor fi utilizate protocoale specifice SDH [G.784], iar în cazul în care acesta este extern 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 nodul sursă, rutele utilizate, la acest nivel fiind necesare protocoale distincte de stabilire a legăturii între operatori.

În capitolul precedent a fost descris atât sistemul de semnalizare nr. 7, care stă la baza semnalizărilor dintre două reţele diferite, cât şi sistemul TMN, a că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 MediereSO 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 de control un nod situat în afara reţelei de transport a SDH. În fig. 4.3 este prezentat un exemplu de configuraţie funcţională SDH specifică procesului de stabilire a unei căi de comunicaţie între un controler de proces situat în afara nodurilor 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 mai sus, ea va trebui validată, ceea ce prespune transmiterea în bandă a codului de identificare asociat punctului de acces conectat. Acesta va trebui validat la celă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 de secţiune potrivită, aceasta fiind apoi permanent comparată cu o valoare limită. Dacă performanţele transmisiunii vor scădea sub acest prag, atunci va fi declarată apariţia unui nou defect. În cazul în care calea sau secţiunea respectivă sunt protejate atunci va fi declanşată procedura automată de refacere 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 de management pot folosi drept suport fizic pentru transmitere fie canalele de comunicaţie integrate în antetul cadrului de transport, fie canale externe mediului SDH.

Pentru a localiza în mod corect canalele fizice folosite ca suport pentru transmiterea informaţiilor de management, în fig. 4.4 a fost prezentată redundanţa de secţiune SOH (“Section OverHead”) 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 sunt reprezentate prin anumiţi octeţi din SOH, pe care îi vom descrie în momentul trecerii în revistă a funcţiei managemetului defectărilor. În cazul în care comunicaţ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, deci un debit total de 768 kbps.

Primele trei canale, D1 ÷ D3, asigură un debit de transport sincron de 192 kbps, dedicat informaţiilor OAM privitoare la echipamentele terminale ale secţiunii de regenerare. Următoarele 9 canale, D4 ÷ D12, alcătuiesc un canal de comunicaţii de date (“DCC – Data Communication Channel”) cu debitul de 576 kbps, dedicat transportului informaţiilor OAM specifice secţiunii de multiplexare.

1 2 3 4 5 6 7 8 9

RS

OH 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



MS

OH 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 OverHead) = Redundanţa secţiunii de regenerareMSOH (Multiplexing Section OverHead) = Redundanţa secţiunii de multiplexare

Protocolul utilizat pentru transferul informaţiilor pe aceste canale este de tipul 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 la ierarhia stratificată OSI a sistemelor SDH. Scopul său este de a transporta informaţ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 de transmisie a canalului folosit. Nivelul 3 al arhitecturii OSI solicită servicii de la nivelul legătură de date prin intermediul primitivelor de servicii. În acelaşi fel nivelul 2 comunică cu nivelul fizic. Primitivele schimbate între nivelul legătură de date ş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ăţi referitoare la serviciul solicitat.

Primitiva RĂSPUNS este utilizată de un anumit nivel pentru a confirma nivelului 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 a confirma î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 sistem OSI, după cum urmează:

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

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

detecţia erorilor de transmisie, de format şi operaţionale survenite pe o conexiune 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 anumite funcţii de control pentru canalele ECC. Astfel, funcţiile de management ale ECC trebuie să îndeplinească următoarele condiţii:

refacerea principalilor parametri ai reţelei ce asigură o funcţionare compatibilă (mărimea pachetelor, calitatea serviciilor, mărimea ferestrei de retransmisie 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 conectare la managerul principal al reţelei. Acest mod de abordare se dovedeşte extrem de util atunci când nu sunt încă interconectate toate inelele SDH, fiind astfel imposibilă folosirea suportului propriu de management. Canalele externe ce vor conecta nodurile SDH la punctul principal de control pot folosi două tipuri de interfeţe cu inelele SDH:

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

interfaţa QB2, tip X25, pentru cazul în care distanţele de interconectare sunt 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 ale nodurilor 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 suportul pentru TMN, prin intermediul canalelor DCC. Folosirea unui sistem extern de transport pentru TMN, deşi extrem de utilă mai ales în faza de instalare a inelelor SDH, poate ridica probleme deosebite de interfaţare, dublate de inconvenientul că astfel se pierde din caracterul integrat al soluţiei oferite pentru acest tip de management.

În următorul paragraf va fi descris modul de implementare a funcţiilor de management 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 Recomandarea M.3010 a ITU-T pentru TMN, clasificare descrisă şi în această lucrare. Conform acesteia 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ă ierarhia de 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 identifica echipamentele defecte. La nivel de echipament acţiunea sa este mai complexă şi presupune detectarea defectărilor, generarea şi monitorizarea semnalelor de alarmă, 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ă spre centrul de management atunci când anumite evenimente/condiţii neacceptabile apar în funcţionarea sa sau sunt sesizate în fluxurile externe pe care acesta le recepţionează. Aceste evenimente sau condiţii trebuie clasificate, de către manager, ca importanţă, în două mari categorii:

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

138



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

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


RSTE (Regeneration Section Terminal Equipment)

= Echipament terminal al secţiunii de regenerare

MSTE (Multiplexing Section Terminal Equipment)

= Echipament terminal al secţiunii de multiplexare

HO PTE

(High Order Path Terminating Equipment)

= Echipament terminal al căii de ordin superior

LO PTE

(Low Order Path Terminating Equipment)

= Echipament terminal al căii de ordin inferior

Din aceste motive, sistemul de management al SDH trebuie să fie capabil să î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 de regenerare

Nivel cale

Nivel secţiune de multiplexare



Condiţii de eroare

LOS (Loss Of Signal) – Lipsă semnal

Atunci când echipamentul nu recepţionează, înainte de de-scrambler, un bit de 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 cel puţin două module de transport corecte consecutiv. După alte 10 sec de funcţionare corectă este anulată şi condiţia de eroare, iar echipamentul resetează semnalul de alarmă, trimiţând spre sistemul de management un mesaj de ieşire din alarma respectivă.

OOF (Out Of Frame) - Desincronizare

În cazul în care timp de 625 µ sec nu este detectată secvenţa corectă de sincronizare (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 detectate două secvenţe de sincronizare corecte consecutive.

LOF (Loss Of Frame) – 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 semnal de 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ă este resetată, iar spre sistemul de management este trimis un mesaj de anulare a condiţiei de eroare.

LOP (Loss Of Pointer) – 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 la dispariţia defectului este înlăturată şi condiţia de eroare, ceea ce conduce la resetarea semnalului de alarmă şi la transmiterea unui mesaj de anulare a alarmei spre sistemul de management.

140



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

Echipamentul de reţea monitorizează şi propria sa funcţionare, în mod similar modului în care monitorizează defectele de semnal. Aceasta presupune monitorizarea blocului de alimentare, blocului de procesare, blocului memoriilor, precum şi altor blocuri funcţionale. Modul în care se realizează aceste operaţii sunt specifice producătorului. La ieşirea din condiţiile normale de funcţionare pentru unul din aceste blocuri este generat un semnal optic de avertizare locală, dublat de transmiterea unui mesaj corespunzător de alarmare spre sistemul de management.

Protocolul de comutare automată a protecţiei

În secţiunea anterioară au fost prezentate principalele condiţii de eroare pe care le poate monitoriza sistemul de management al SDH şi modul în care acesta reacţionează la detectarea unei condiţii de eroare. Pentru a putea asigura o funcţionare continuă, la parametrii impuşi, a unei secţiuni de multiplexare sunt prevăzute aşa numitele canale de rezervă. Un canal de rezervă 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 la ambele 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 management al 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ării chiar a acestor octeţi, ceea ce trebuie să conducă la generarea unei condiţii de eroare specifică.

Semnale de alarmă şi eroare

După cum a fost prezentat în secţiunea dedicată condiţiilor de eroare, atunci câ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 se referă la pierderea pointerului pentru cadrele dintr-o cale de ordin inferior, deci atunci când apare defectul LO_LOP.

Pentru semnalele de tip RDI pot fi identificate în mod similar trei sub-tipuri distincte, 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 ordin superior o condiţie HO_LOP sau dacă la acest nivel au fost recepţionate din amonte MS_AIS sau HO_AIS;

LO_RDI: este generat dacă la nivelul căii de ordin inferior a fost detectat un defect de pierdere de pointer, deci LO_LOP sau în cazul în care a fost 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 în amonte, spre echipamentul de la care se recepţionează fluxul informaţional şi sunt 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 la care sunt generate, astfel:

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

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

LO_REI: reprezintă un retur distant la BIP_2, fiind generat la nivelul căii de 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 fi divizată î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 echipamentele din reţea, prin conectare locală sau distantă la facilităţile interne de testare ale acestora.

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

Prin funcţiile de rebuclare pot fi testate separat, progresiv, prin izolare, toate tronsoanele 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, fie colectarea 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 15 minute ş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 Switching Duration

= Durata comutării protecţiei.

Pentru o analiză pertinentă a datelor privitoare la performanţa reţelei este necesară asigurarea memorării unei anumite istorii funcţionale a obiectului monitorizat. 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 cea de o zi. Pentru fiecare fereastră a fost definit câte un registru pentru situaţia curentă, un altul pentru situaţia anterioară şi un număr nedefinit de regiştri pentru ultimele n intervale recente. Toţi aceşti regiştri pot fi citiţi la cerere sau în mod regulat, actualizarea sau citirea informaţiei făcându-se în mod obligatoriu fără pierderi.

Pentru toate mărimile monitorizate au fost stabilite nişte limite de variaţie maxime, 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ţiunea anterioară.

Această funcţie de management al performanţelor oferă informaţii foarte utile atât pentru funcţia de defectări cât şi pentru funcţia de management al configuraţ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ă o bună configurare a resurselor sistemului de transport şi este util atât în etapa de instalare 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, deci sunt folosite soluţiile proprietare ale furnizorului, necesare punerii în funcţiune a întregului sistem. În etapa operaţională deja trebuie stabilite anumite metode de control a parametrilor reţelei în vederea optimizării performanţelor acesteia. Principalul instrument aflat la dispoziţia managerului pentru optimizarea configuraţiei este funcţia de comutare a protecţiilor. Pentru o folosire uşoară şi corectă, aceste funcţii de comutare trebuie să poată funcţiona în patru regimuri distincte:

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

regim cu comutare forţată a intrării/ieşirii din funcţiune a circuitelor de protecţ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 a circuitelor de protecţie (cunoscut ca APS).

Aceste trei funcţii de management prezentate mai sus sunt cele mai importante ş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 de management

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

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

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

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

Nivelul fizic este constituit de canalele DCC, care operează la viteza de 192 kbps în secţiunea de regenerare, folosind octeţii D1 ÷ D3, iar în secţiunea de multiplexare 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” – Serviciu de transfer neconfirmat al informaţiilor), fie AITS (“Acknowledged Information Transfer 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 transfera informaţiile de la nodul sursă la cel destinaţie, este necesar ca fiecare nod din reţea să poată lucra fie ca nod intermediar, fie ca nod final. În acest fel, nodurile intermediare pot genera, la rândul lor, informaţii de control al rutării, necesare rutării NPDU-urilor.

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

Pentru nivelele 5 şi 6 specificaţiile funcţionale sunt cele descrise în recomandările X.215 şi X.225 pentru nivelul sesiune şi X.216 şi X.226 pentru nivelul 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 prezentat nivelul 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ă pentru a 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ă fie informat despre modul în care se desfăşoară operaţia comandată.

145

SM-ASE

CMISE

ROSEACSE

Niv

el A

plic

aţ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 pentru managementul SDH impune o metodă orientată pe obiecte de tratare a componentelor reţelei.

Pentru managementul reţelei SDH, CMISE oferă următoarele primitive şi servicii 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 utilizat standardul ASN.1.

Se poate afirma, la finalul prezentării, că managementul SDH este o aplicaţie a TMN, aplicaţie ce respectă particularităţile transmisive ale mediului folosit 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 SDH implementate la noi în ţară. Au fost folosite drept suport canale exterioare sistemului de transmisiuni, iar protocolul realizat este o adaptare a protocolului LAPD la condiţiile particulare ale aplicaţiei respective.

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

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

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 de realizare a unui sistem de management dedicat unei reţele SDH, funcţională la ora actuală în cadrul reţelei de fibră optică a RomTelecom. Sistemul a fost proiectat pentru a asigura principalele funcţii de management ale tronsonului B ale reţelei de transmisiuni pe suport de fibră optică, realizat cu echipamente Fujitsu. În fig. 4.9 este prezentată configuraţia reţelei de transmisuni pentru care a 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 140 Mbit/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 final ca făcând parte dintr-un sistem SDH. Tipurile de alarme, configuraţii de lucru şi modul de monitorizare sunt specifice sistemului SDH din care fac parte şi au fost descrise din punct de vedere teoretic în secţiunea anterioară.

Echipamentele care asigură suportul de transmisuni pe fibră optică sunt de 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 de vedere 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 de administrat (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 de management.

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

4.2.2 Baza de date a sistemului de management

Pentru a putea asigura toate aceste funcţiuni a fost creată o bază de date relaţională, inspirată din cerinţele impuse de OSI pentru MIB şi care conţine principalele mărimi folosite de funcţiile de management. Baza de date conţ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 integer2. NUME_STAŢIE text3. ID_CANAL integer4. NR_RACKURI integer5. NR_RACKURI_DIST integer6. ADR_PROTOCOL integer7. ECA_INSTALAT integer8. ID_DIST_ST integer9. NR_RACK_CON_DIST integer

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

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

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

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

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

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

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

ECA_INSTALAT - indică sistemului de management dacă staţia respectivă este deservită de propriul agent de management (ECA – Echipament de Colectare a Alarmelor) sau este administrată de la distanţă de la o staţie vecină;

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

NR_RACK_CON_DIST - acest câmp este asociat, de asemenea, unei staţii neechipate cu ECA şi indică numărul rack-ului din staţia vecină la care este 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 integer2. ID_STAŢIE integer3. NO_RACK integer4. NO_BLOCK integer5. NO_UNIT text6. ID_TIP integer7. 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 integer2. 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 de management (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 suplimentare referitoare 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 integer2. 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Ă integer2. COD_ALARMĂ text3. DESCRIERE_ALARMĂ text

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

ID_COD_ALARMĂ - acest câmp indică ce tip de alarmă a apărut pe o anumită 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Ă integer2. ID_STAŢIE integer3. ID_UNIT integer4. ID_COD_ALARMĂ integer5. APARIŢIE datetime6. DISPARIŢIE datetime7. DURATĂ long integer8. READED integer9. 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 este urmă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 în care 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ÂMP1. ID integer2. ID_UNIT integer3. DATA_ORA_MAS datetime4. ULTIM_MAS integer5. BER float6. EB float7. EFS float8. ES float9. SES float

10. DM float

Semnificaţia câmpurilor folosite în cadrul tabelei de ALARME este urmă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 fost actualizate sau nu;

BER, EB, EFS, ES, SES, DM - aceste câmpuri conţin valorile mă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 de transmisiuni;

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

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

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

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

Nr. crt. CÂMP TIP CÂMP1. USER_NAME text2. FLAG_ALARME integer3. ID_MPT integer4. 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 drept obiectiv a fost realizată prin intermediul unui sistem de management complex, bazat pe tehnologia client-server şi care este compus dintr-o unitate centrală de management (PCS – Punct Central de Supraveghere) şi un număr de agenţi locali 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 un număr de 7 agenţi de management au fost instalaţi în ţară, conform dispunerii din fig. 4.11. După cum s-a putut observa şi din definirea bazei de date a sistemului, un agent de management instalat într-o staţie poate servi şi echipamentele aflate în staţiile vecine, prin intermediul unor canale de comunicaţii închiriate.

Sistemul construit respectă specificaţiile generale ale unui sistem de management, 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 management cu procesare distribuită, prezentate în cap. 2. După cum s-a putut observa şi prin trecerea în revistă a principalelor mărimi care sunt stocate în baza de date a sistemului (tab. 4.1 ÷ tab. 4.8), acest sistem corespunde specificaţiilor unui sistem de management al SDH (cap. 4.1).

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

Fiecare din aceste unităţi funcţionale distincte este prevăzută, în mod suplimentar, cu un contact static, flotant, prin închiderea acestuia, semnalizându-se dispozitivului ECA existenţa unei alarme funcţionale. În momentul recepţionării semnalului de alarmă, ECA se conectează automat la sistemul respectiv şi pe baza unui dialog interactiv, de tip client-server, citeşte starea 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, prin modem, 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 de management

Canal digital de management

Staţie prevăzută cu agent de management şi cu manager de reţ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 bps

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ţă

Interfaţă

Interfaţă

Dispozitiv Diagnoză

Interfaţă

Dispozitiv Diagnoză

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ă de alimentare

A0

A1

A2

…

A5

S1

S2

S3

S4 …

S8

INTRS 232

A B C E R

Adrese MUX Port serial

Po

rt i

ntr

ări

Port ieşiri

Sistem cu micro-controllerPC

INT RS232INT 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

Po

rt in

trăr

i

A0A1A2

…

A5 Busul de date BD0÷ 7 Po

rt ie

ş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

Sp

re IC

A

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ă a unui anumit echipament subordonat acestuia. La primirea acestei comenzi, ECA începe un dialog cu echipamentul respectiv, culege informaţiile cerute, le formatează, 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 managerul sistemului.

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 la PCS, fie local, de la un laptop, pentru aceasta ehipamentul fiind prevăzut, în mod suplimentar, cu un port de acces. Această ieşire poate fi conectată serial, asincron, cu viteza de 9600 bps la un calculator pentru efectuarea diagnozei modulului.

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 tensiune flotantă de +5V, la un curent nominal 150 mA. Este prevăzută cu protecţie la suprasarcină de curent, la un curent de aproximativ 500 mA decuplând automat modulele care se alimentează de la ea.

Sursa de alimentare destinată ECA, este un convertor DC-DC, în comutaţie, care transformă tensiunea continuă de 48 V (20V ÷ 80V) de alimentare a ramelor din oficiu PTT, într-o tensiune continuă izolată şi stabilizată 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 la cristalul de cuarţ de 15 MHz ataşat microcontrolerului.

Achiziţia datelor de la IAC se realizează cu ajutorul unui bloc de comunicaţ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 electrice fiind compatibile TTL. Comanda IAC, pentru selecţia canalului de comunicaţie ce 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 echipamente

159

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, notate cu 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 un calculator 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 15 MHz 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 sunt memorie EPROM (necesare păstrării aplicaţiilor), în această configuraţie fiind plasaţi între adresele 0H ÷ 7FFFH şi 32 Kb memorie RAM, poziţionaţi între adresele de memorie 8000H ÷ 0FFFFH. În memoria RAM pot fi încărcate şi rulate programe, astfel că sistemul permite şi rularea unor variante îmbunătăţite ale 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 flotante de alarmă situate pe rack-urile ce trebuiesc monitorizate. Închiderea unuia din aceste contacte, în cazul apariţiei unei alarme la rack-ul respectiv, conduce la apariţia unui “zero” electric la intrarea portului Ai respectiv, sistemul fiind astfel anunţ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ări majore 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 transmite comenzi către echipamentele aflate în subordine. Nivelele electrice sunt adaptate în ambele direcţii de către IAC, aceasta făcând translatarea de la nivele de ± 12V specifice echipamentelor la nivele de 0/5 V ale UC-ului.

160

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

Deci, IAC asigură legătura logică între UC şi echipamentele de transmisiuni pe suport optic aflate sub supraveghere, permiţând transferul bidirecţional de informaţii între PCS şi echipamentele terminale optice, astfel că:

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 ce urmează a fi monitorizate şi controlate. Interogarea echipamentelor se realizează în două situaţii distincte, astfel:

atunci când PCS-ul o solicită în mod expres pentru a afla starea acestora sau pentru a o modifica, prin pornirea unui program de “terminal virtual” prin care operatorul aflat la punctul central poate modifica, pe baza unui meniu 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 interogarea echipamentului care a semnalizat o stare de proastă funcţionare. Informaţiile obţinute de la echipament sunt transferate, prin intermediul modemului, spre PCS, 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 calitatea canalului respectiv în momentul realizării transferului.

Datorită importanţei transferului corect al datelor, acesta este realizat pe baza unui protocol de comunicaţie protejat la erori ce pot atinge pragul critic de 10-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 blocul transmis anterior sau la cererea expresă a corespondentului. Am construit acest protocol 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 a managementului defectărilor (cap. 1), în particular funcţii de diagnosticare.

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

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

161

nivel local: poate fi comandată efectuarea testelor complete ale aparatului de la un calculator personal sau un terminal compatibil VT100 conectate la portul local de acces;

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

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

Controlul şi monitorizarea sistemului

Controlul şi monitorizarea aparaturii de transmisuni pe suport optic se realizează, prin intermediul ECA, de la un Punct Central de Supraveghere (PCS). Dialogul între PCS şi ECA este de tip interogare-răspuns, fiind structurat 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, monitorizarea performanţ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 principalele blocuri aflate între operatorul uman aflat la consola PCS şi terminalul de transmisiuni care este monitorizat.

Aceste blocuri funcţionale sunt astfel constituite încât urmăresc structura logică 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 Interfaţă 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 date pentru a culege datele necesare. Acest modul preia apoi cererea, individualizează abonatul căruia îi este adresată şi o transmite în formatul necesar 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 modulul corespunzător, MIfC, din ECA, căruia îi este adresată. MIfC din ECA preia mesajul, îl decodifică şi îl transmite mai departe către modulul de control şi monitorizare. Acesta interpretează cererea şi interoghează la rândul său unitatea 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 un schimb de informaţii, bidirecţional, pe baza unui protocol de comunicaţie, în mod “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-a preferat un protocol de comunicaţie asincron, adaptat principalelor cerinţe ale acestor 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 cadre utilizate î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 de control

erori

ComandăECA

Flag2

Cadru de comandă

Flag3 InformaţieCâmp de control

eroriFlag4

Cadru de informaţie

Flag1 AlarmeCâmp de control

eroriFlag2

Cadru de supraveghere

Delimitarea cadrelor schimbate între ECA şi PCS se face prin intermediul indicatorilor de început şi sfârşit cadru F1 şi F2. Fiecare cadru conţine un câmp de 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 de informaţie în funcţie de destinatarul comenzii. Pentru comenzi care îi sunt adresate, ECA răspunde tot cu cadre de comandă, iar pentru comenzi care sunt adresate rack-ului răspunde numai cu cadre de informaţie;

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

cadrele de supraveghere se schimbă între ECA şi PCS numai la iniţ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 etape este unitatea de management a sistemului, PCS-ul.

Verificarea permanentă a calităţii legăturii este realizată prin transmiterea periodică a unor “cadre de supraveghere”, în paralel cu efectuarea unui calcul statistic pentru determinarea aproximativă a ratei de erori existentă la un moment 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 pachetului anaterior. 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 pe ECA.

164

F1 a c NrCanalRegStAl r NrRec1 NrRec2 CTRL F2

F1 a p NrPortRegStAl CTRL F2

F1 a s RegStPRegStAl p NrPort CTRL F2

F3 Informaţie CTRL F4

F1 a p NrPortRegStAl CTRL F2

F1 a c NrCanalRegStAl CTRL F2

F1 a c NrPortTRegStAl t e/g CTRL F2

F1 a c NrRec1RegStAl 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 un modul supervizor de reţea (MSR), ca în fig. 4.18.

MSR

Legătură de date

Reţea

MCNivel 2

OSI

Nivel 3 OSI

Mif

C d

e la

PC

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, fiecare specializat 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 de procesare 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 flux de 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 la PCS (fig. 4.20);

programul de supraveghere şi procesare al alarmelor existente pe rame: monitorizează permanent starea intrărilor de alarme dinspre ECA, având un 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 cu avizul programului de supervizare execută aceste comenzi;

programul de verificare funcţională a porturilor ECA: la iniţiativa interpretorului de comenzi poate iniţia şi desfăşura un program de verificare funcţională parţială sau totală a porturilor ECA, prin transmiterea unei secvenţe de testare spre acestea şi interpretare a datelor recepţionate ca rezultat al testului (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 minicicluri de 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 executa atâ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 asupra modulelor interne ale echipamentului, cât şi asupra conexiunilor externe ale acestuia.

Initializare sub procesare

alarme167

Formez masca de citire a alarmelor

Citesc starea alarmelor de la

porturi

Verific RegStAlVechi ≠

RegStAlNoi

Întârziere 20 ms

Recitesc starea alarmelor de la

porturi

VerificRegStAlVechi ≠

RegStAlNoi & dacă cele două citiri sunt identice

ReactualizezRegStAl

Afişez modificarile la DGZ şi PCS

Sfârşit procesare alarme

NU

NU DA

DA

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

Iniţializare sub comunicaţie

ramă168

Temporizare 30 ms

Transmit un caracter spre PCS;Incrementez contorul transmisiilor.

Temporizare pre-programată

Terminat transmisie ?

Temporizare 30 ms

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

recepţionate.

Timp scurs ≤ 5 sec.

Contoar car. Rec. ≤ 80

Descarc datele recepţionate în buffer-ul de

recepţie ramă

Sfârşit subrutină de comunicaţie cu rama

NUDA

DANU

NU

DA

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

Iniţializare sub verificare 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ă verificare stare port

DANU

DANU

DANU

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

Iniţializare sub recepţie de la

PCS

170

Caracter nou recepţionat ?

Cadru în curs de

CaracterRec. = F1 ?

CaracterRec. = F2 ?

Descarc car. Rec. în buffer-ul temporar

Incrementez contoar car.

Rec.

Contor car. Rec ≤ Max

Resetez cadrul în curs;Reiniţializez contoarele.

Calculez caracterul de control CTRL

Verific CTRL corect ?

Descarc buffer-ul temporar în cel de

recepţie

Verifică datele din punct de vedere

sintactic şi le transferă buclei

principale

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

NU DA

DA NU

NU DA

DA

Resetez cadrul în curs;Reiniţializez contoarele.

NU DANU

Setez indicatorul cadru în curs de recepţie

NU

DA

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

Iniţializare program

principal ECA

Testare principalele componente ale ECA

Lansează subrutină verificare alarme

171

Testele interne se efectuează automat la pornire şi verifică buna funcţ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ţie de la PCS ?

Verifică recepţie de la consolă ?

Lansează subrutină procesare meniu

Lansează subrutină procesare comunicaţ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ă, prin operaţ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 şi compararea 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ă vizual de către operatorul care efectuează testul.

Verificarea porturilor de comunicaţie: presupune existenţa unui port 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ării comunicaţ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-se primirea aceleiaşi secvenţe.

La verificarea alarmei, simpla introducere a conectorului special de alarme pe un port anume ar trebui să conducă la afişarea unei alarme pe canalul 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 la distanţă. Pentru toate aceste tipuri de teste trebuie intrat în modul linie de comandă 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 modemul distant se pot trimite acum scurte mesaje care trebuie să fie reîntoarse de bucla digitală realizată local. Pentru ieşire din acest mod de testare se trimite spre modemul 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 prin comanda “atz”, care va reseta modemul de la PCS. Apoi se va încărca în acest modem comanda “at&m4&w”, urmată de <CR>, iar la primirea răspunsului “OK!” modemul va fi resetat pentru încărcarea automată a noilor parametri prin comanda “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, pe ecranul PCS-ului va apărea mesajul “CONNECT TO 9600”. Acum poate fi efectuat testul de buclare digitală la distanţă, trimiţându-se un set de caractere “+++” pentru trecerea în modul comandă, după care prin trimiterea setului de caractere “at&t6”, urmate de caracterul <CR> se va trece modemul distant în starea de buclă digitală la ieşirea spre ECA. Odată efectuată buclarea la distanţă pot fi trimise orice caractere de la consolă, acestea ajungând la modemul distant de unde se vor reîntoarce la modemul generator, care le va redirecţ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 interpretorului de 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 prin caracterul “#” şi conţin numai caractere text mici;

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

Comenzile destinate ECA pot avea până la 40 de caractere ASCII lungime, trebuie să înceapă obligatoriu cu caracterul “#”, să conţină numai litere mici 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 ECA pentru formatare;

• I, câmp de informaţie care conţine caracterele recepţionate de la ramă, 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 la terminalul de DGZ şi cel de la PCS se afişează caracterul ”c” urmat de numărul canalului introdus;

“#d”, pentru setarea timpului de citire a unei rame. După introducerea acestei comenzi va fi afişat un mesaj privind valoarea acestui interval, valoare care este măsurată în multipli de 500 de ms. Acest mesaj va fi formatat în funcţ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ă în acel 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 acest interval temporal între 500 ÷ 4500 ms.

Observaţie: La pornirea programului indicele de multiplicare este setat la 2, 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 ÷ 180 ms, î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, pe consola 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 era de 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 5 secunde introducerea unei valori pentru indicele de multiplicare, în intervalul “0” ÷ “9”. Dacă este depăşit timpul de aşteptare sau valoarea introdusă nu este în intervalul impus, programul va ignora această comandă şi va reveni în starea de aşteptare. Dacă condiţiile sunt îndeplinite corect, în funcţie de regimul selectat, 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 la 3, deci intervalul iniţial între transmisiile succesive a două caractere este de 60 de ms.

“#g” este destinat afişării la consola PCS a registrului de stare al porturilor. 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 al

porturilor; 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 de mai jos:

********************| Meniu comenzi || a - citesc Al. || b - retransmisie|| c - sel. port || d - sel. timp || f - sel. pauza || g - citesc StP. || l - meniu || m - regim PCS |

177

| 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) la portul de supervizare (PCS). De asemenea, va comuta modul de lucru trecând în modul real, cu detecţie de erori. După efectuarea acestei comenzi pe ecranul terminalului de diagnoză, ca şi pe cel de supervizare va apare mesajul:

********************| Comanda la PCS |********************

“#n” va transfera comanda de la portul de supervizare (PCS) la portul de diagnoză (DGZ). După efectuarea acestei comenzi pe ecranul terminalului 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 drept rezulat selectarea unui canal de lucru real pentru restul comenzilor ce vor fi trimise de la operator spre ramă. În mod implicit este setat primul canal spre rame, canalul 1, deci portul 2. Odată introdusă această comandă, în funcţie de modul de lucru în care se află setată ECA, pe ecranul terminalului de diagnoză, cât şi pe cel al portului de supervizare pot apare urmă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; a, caracterul “a”, semnifică afişarea registrului de alarme; A, registrul de alarme la care s-a adăugat valoarea 48D;

178

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 între recepţionarea carcaterului “p” şi recepţionarea numărului portului, iar cazul depăşirii acestui interval, programul se întoarce automat în bucla principală;

dacă în loc de numărul portului dorit se introduce “CR”, indiferent de regim, 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 regimul real de lucru, cu detecţie de erori. Confirmarea schimbării modului de lucru se va 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 ordine descrescătoare. Pentru fiecare test în parte vor fi afişate rezultatele ca le testele efectuate prin comanda “v”;

“#u” are drept rezultat comutarea din regimul real de lucru în regimul demonstrativ. Confirmarea schimbării modului de lucru se va face prin afişarea la 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 la blocare, a fost prestabilit un interval maxim de 5 secunde în care poate fi introdusă cifra corespunzătoare valorii portului testat. În cazul în care acest prag va fi depăşit, programul se va întoarce în bucla principală, aşteptând introducerea altei comenzi. Aceeaşi decizie va fi luată şi în cazul în care numărul portului nu este introdus corect, în intervalul impus.

Pentru verificare va fi trimisă, spre portul selecţionat, o secvenţă de caractere 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 fi recepţ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:

• regim demo: Pe ecranul terminalului conectat la portul DGZ va apare numărul canalului testat, urmat de caracterul “G” în cazul unei funcţionări

179

corecte sau de caracterul “E” în cazul unei erori. În paralel este asigurată o confirmare vizuală pentru operator, prin intermediul LED-urilor situate pe panoul frontal: dacă rezultatul testului este pozitiv se va aprinde timp de o secundă, în mod continuu, LED-ul corespunzător canalului respectiv, iar în cazul unei funcţionări incorecte se vor aprinde alternant (de 4 ori consecutiv, timp de 80 ms), 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ătorul format: “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 şi registrul cu starea porturilor, astfel că pentru test reuşit va fi setat bitul corespunzător numărului portului (porturile sunt numerotate de la 0 la 7, la fel ca 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ă cu efectuarea unui reset “la cald”. Confirmarea acceptării comenzii se va face vizual, prin afişarea la consola activă a următorului mesaj:

********************|ECA SE RESTARTEAZA|********************.

“#y” comandă de acces la modul de lucru linie de comandă a modemului 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 ASCII lungime, trebuie să se termine obligatoriu cu caracterul “CR”, să conţină numai litere mari sau cifre de la “0” la ”9”.

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

Ieşirea din modul ascultare se va face fie la expirarea timpului setat, fie la depăşirea numărului limită de caractere recepţionate, adică la recepţionarea celui de al 81lea caracter. Caracterele recepţionate vor fi formatate prin

180

adăugarea caracterului “LF” înaintea fiecărui caracter “CR” recepţionat de la ramă, 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 comenzi accesibile utilizatorului. Transmiterea iniţială a datelor recepţionate spre PCS se va face respectând un format anume, în funcţie de regimul de lucru în care se află ECA.

• regim demo: Datele vor fi precedate de un antet care va anunţa de la ce port au fost recepţionate şi numărul real de caractere recepţionate de la 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 facilita detecţia de erori la PCS şi anume: “F1aAcCrR1R2CTRLF2F3ICTRLF4”, unde câ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 a managementului în cadrul reţelelor SDH.

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

181

Partea a doua a capitolului este dedicată prezentării contribuţiilor pe care le-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 a alarmelor, ECA, în principal unitatea centrală şi interfaţa de comunicaţie cu clientul;

proiectarea protocolului de comunicaţie folosit ca suport pentru sistemul de 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 cu obiectele de administrat);

proiectarea şi implementarea protocolului de comunicaţie dintre sistemul de 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 de management, realizată conform modelului MIB. Au fost utilizate pentru transportul informaţiilor de management canale de date externe sistemului (DCC), iar protocoalele de comunicaţie le-am realizat particularizând modelul folosit pentru canalul comun de semnalizare a cărui realizare am descris-o în capitolul anterior. Sistemul de management pe care l-am realizat este operaţional din perioada decembrie 1999 pe tronsonul B de transmisiuni pe suport de fibră optică al RomTelecom şi funcţionează în condiţii optime, ceea ce dovedeşte viabilitatea modelului de reţea de management realizată şi robusteţea protocoalelor de comunicaţii implementate.

182

managementul reţelelor sdh – teorie şi implementare practică

Documents