Sunteți pe pagina 1din 52

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
www.cartiaz.ro – Carti si articole online gratuite de la A la Z

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.

NM NM
afluenţi


ADM MUX

NM

DCS

NM
 conexiune fizică
afluenţi

MUX  Informaţii de redundanţă încorporată

 Canale auxiliare dedicate


managementului de reţea

Semnificaţia notaţiilor folosite:

MUX  (Multiplexer) = Multiplexor


ADM  (Add Drop Multiplexer) = Multiplexor de inserţie-extracţie
DCS  (Digital Cross-connect System) = Sistem digital de interconectare
NM  (Network Management) = Management de reţea

Fig. 4.1. Exemplu de sistem de management al SDH

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
www.cartiaz.ro – Carti si articole online gratuite de la A la Z

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.
Nivel cale
Nivel secţiune
multiplexare
Nivel fizic Nivel secţiune
regenerare

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

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
www.cartiaz.ro – Carti si articole online gratuite de la A la Z

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 DM SO

OA OA

FER-FMA FER-FMA DM-FMA SO-FMA

FCM FCM FCM FCM

Qx Q3

Semnificaţia notaţiilor folosite:

ER A, ER B  Element de Reţea A, B
OA  Obiect Administrat
FER  Funcţie Element de Reţea
DM  Dispozitiv de Mediere
SO  Sistem de Operaţii
FMA  Funcţie de Management la nivel Aplicaţie
FCM  Funcţie de Comunicaţii pentru Mesaje

Fig. 4.3. Exemplu configuraţie management SDH implicată în stabilirea unei căi
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
www.cartiaz.ro – Carti si articole online gratuite de la A la Z

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
RSOH

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 X
PTR. 4 H1 h1 h1 H2 h2 h2 H3 H3 H3

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

MSOH
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

Semnificaţia notaţiilor folosite:

RSOH  (Regeneration Section OverHead) = Redundanţa secţiunii de regenerare


MSOH  (Multiplexing Section OverHead) = Redundanţa secţiunii de multiplexare

Fig. 4.4. Structura SOH pentru cadrul STM-1

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.

Nivel 3 Nivel 3

CONFIRMARE CERERE INDICAŢIE RĂSPUNS

PAS

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

Nivel 2 Nivel 2

Protocol punct-la-punct la nivelul


Legătură de Date

PAS – Punct de Acces la Serviciu

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

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
www.cartiaz.ro – Carti si articole online gratuite de la A la Z

 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
www.cartiaz.ro – Carti si articole online gratuite de la A la Z

 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 RSTE
RSOH
Nivel secţiune de
regenerare

RSTE RSTE
MSOH

Nivel secţiune de
multiplexare

RSTE RSTE
HO POH

Nivel cale

RSTE RSTE
LO POH

Semnificaţia notaţiilor folosite:

RSTE  (Regeneration Section = Echipament terminal al secţiunii de


Terminal Equipment) regenerare
MSTE  (Multiplexing Section Terminal = Echipament terminal al secţiunii de
Equipment) multiplexare
HO  (High Order Path Terminating = Echipament terminal al căii de ordin
PTE Equipment) superior
LO  (Low Order Path Terminating = Echipament terminal al căii de ordin
PTE Equipment) inferior

Fig. 4.6. Ierarhie de management SDH

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
www.cartiaz.ro – Carti si articole online gratuite de la A la Z

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
www.cartiaz.ro – Carti si articole online gratuite de la A la Z

Î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
www.cartiaz.ro – Carti si articole online gratuite de la A la Z

 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
www.cartiaz.ro – Carti si articole online gratuite de la A la Z

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 codului


ES  Errored Second = Secundă eronată
SES  Severly Errored Second = Secundă sever eronată
UAS  UnAvailable Second = Secundă indisponibilă (nefuncţională)
PSC  Protection Switching = Număr de comutări ale protecţiei
Count
PSD  Protection Switching = Durata comutării protecţiei.
Duration

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
www.cartiaz.ro – Carti si articole online gratuite de la A la Z

 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).

CMISE
Nivel 7 →
ACSE/ROSE

Nivel 6 → X.216 şi X.226

X.215 şi X.225
Nivel 5 →

Nivel 4 → ISO 8073/AD2

ISO 8473/AD3
Nivel 3 →

Nivel 2 → LAPD [Q.921]


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

Nivel 1 → DCC

Fig. 4.7. Stivă de protocoale pentru ECC

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

SM-ASE
Nivel Aplicaţie

CMISE

ACSE ROSE

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

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

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.

Legendă

 Staţie de comutaţie centrală


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

BACĂU

 Staţie intermediară
SASCUT

 Staţie regenerator
ADJUD
 Staţie terminală
FOCŞANI
 Fibră optică de 140 Mb/s

GALAŢI

BRĂILA

ÎNSURĂŢEI

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

FETEŞTI
SLOBOZIA CERNAVODĂ

AFUMAŢI MEDGIDIA

BUCUREŞTI
CONSTANŢA

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

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
www.cartiaz.ro – Carti si articole online gratuite de la A la Z

structura unor asemenea blocuri şi cartele din perspectiva sistemului de


management.

rack 1 rack 2 rack 3


cartele

B1 B1 B1

Bloc 3
conector MPT E-SV E-SV E-SV

B2 B2 B2

Bloc 2
blocuri

B3 B3 B3

Bloc 1

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

Fig. 4.10. Structura şi localizarea obiectelor 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
www.cartiaz.ro – Carti si articole online gratuite de la A la Z

 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ÂMP


1. ID_STAŢIE integer
2. NUME_STAŢIE text
3. ID_CANAL integer
4. NR_RACKURI integer
5. NR_RACKURI_DIST integer
6. ADR_PROTOCOL integer
7. ECA_INSTALAT integer
8. ID_DIST_ST integer
9. NR_RACK_CON_DIST integer

Tab. 4.1. Structura tabelei de STAŢII

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
www.cartiaz.ro – Carti si articole online gratuite de la A la Z

Nr. crt. CÂMP TIP CÂMP


1. ID_UNIT integer
2. ID_STAŢIE integer
3. NO_RACK integer
4. NO_BLOCK integer
5. NO_UNIT text
6. ID_TIP integer
7. FLUX text
8. OBSERVAŢII text

Tab. 4.2. Structura tabelei de UNITĂŢI

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ÂMP


1. ID_TIP integer
2. TIP text
3. DESCRIERE text
Tab. 4.3. Structura tabelei de TIPURI

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
www.cartiaz.ro – Carti si articole online gratuite de la A la Z

Nr. crt. CÂMP TIP CÂMP


1. ID_CANAL integer
2. COM_PORT text
3. INSTALAT integer

Tab. 4.4. Structura tabelei de CANALE

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ÂMP


1. ID_COD_ALARMĂ integer
2. COD_ALARMĂ text
3. DESCRIERE_ALARMĂ text

SemnificaţiaTab. 4.5. Structura


câmpurilor tabelei
folosite de CODURI_ALARMĂ
î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ÂMP


1. ID_ALARMĂ integer
2. ID_STAŢIE integer
3. ID_UNIT integer
4. ID_COD_ALARMĂ integer
5. APARIŢIE datetime
6. DISPARIŢIE datetime
7. DURATĂ long integer
8. READED integer
9. NO_RACK integer

Tab. 4.6. Structura tabelei de STAŢII

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

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ÂMP


1. ID integer
2. ID_UNIT integer
3. DATA_ORA_MAS datetime
4. ULTIM_MAS integer
5. BER float
6. EB float
7. EFS float
8. ES float
9. SES float
10. DM float

Tab. 4.7. Structura tabelei de FUNC_SPEC

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
www.cartiaz.ro – Carti si articole online gratuite de la A la Z

 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ÂMP


1. USER_NAME text
2. FLAG_ALARME integer
3. ID_MPT integer
4. CMD_MPT text
5. ECRAN_MPT text
6. REQUEST_WKS text
7. ANSWER_WKS text
8. INTERDICTIE integer

Tab. 4.8. Structura tabelei de UTILIZATORI

 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
www.cartiaz.ro – Carti si articole online gratuite de la A la Z

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.

Legendă
 Staţie prevăzută cu agent de
 Staţie de comutaţie centrală BACĂU
management

 Staţie intermediară  Canal digital de management


SASCUT

 Staţie regenerator  Staţie prevăzută cu agent de


ADJUD management şi cu manager de
 Staţie terminală reţea

FOCŞANI
 Fibră optică de 140 Mb/s

GALAŢI

BRĂILA

ÎNSURĂŢEI

ŢĂNDĂREI

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

FETEŞTI

SLOBOZIA CERNAVODĂ
URZICENI CĂZĂNEŞTI

AFUMAŢI MEDGIDIA

BUCUREŞTI
CONSTANŢA

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

155
PCS
(platformă Windows NT)
Interfaţă multiport serială
asincronă
1 ... 9

Modem asincron Modem asincron


v = 9600 bps Interfaţă v = 9600 bps

Dispozitiv Dispozitiv
Diagnoză Diagnoză
7 Modem asincron Modem asincron
v = 9600 bps v = 9600 bps
Interfaţă
Interfaţă
Interfaţă serială Interfaţă serială Interfaţă serială Interfaţă serială
asincronă asincronă asincronă asincronă
v = 9600 bps v = 9600 bps v = 9600 bps v = 9600 bps

.......
ECA 1 ECA 8
(platformă microcontroller (platformă microcontroller
8x552) 8x552)
Porturi seriale asincrone Porturi seriale asincrone
V = 1200 bps V = 1200 bps

1 2 ... 6 Interfaţă 1 2 ... 6

Porturi seriale asincrone v = 1200 bps Porturi seriale asincrone v = 1200 bps

Ramă Ramă

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

156
RAMA 1 RAMA 2 RAMA 3 RAMA 4 …… RAMA 6
PCS

IO - 2 IO - 3 IO - 4 IO - 5 IO - 7
GND I.A.C.
MODEM

INT RS232 +5V INT RS232 INT RS232 INT RS232 INT RS232 INT RS232
A1 A2 A3 A4 A6

MULTIPLEXOR
DIGITAL

+5 V GND
A B C E R

Port intrări
A0
Adrese MUX Port serial
PORT TESTARE
A1
INT PC
A2 RS 232
Sistem cu micro-controller
Sursă de
aliment

are Port ieşiri


R1 R2 R3 R4 … R8
A5
S1 S2 S3 S4 S8
S.A. …
+ 48 V - U.C.

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


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

Port TEST
E ER157R
Port intrări

Port ieşiri
RAM (32kB) 87C552 EPROM (32kB) E R E
8000H ÷ 0FFFFH 0000H ÷ 7FFFH
BD0÷ 7 BD0÷ 7 BA0÷ 7 Busul BD0÷ 7 BA0÷ 7 INT.BD
RS 232 R
C5210
B
A Busul
Busul dede
de control
adrese
date BD
BA0÷0÷
77 0÷ 7
S84321…

Spre ICA
158

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


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.

Legendă:
PCS MApl – Modul Aplicaţie;
MBD – Modul Bază de Date;
MApl
MIfC – Modul Interfaţă de Comunicaţie;
MCM – Modul Control şi Monitorizare;
UTO – Unitate Terminală Optică.
MBD

ECA
UTO
MIfC IfC MCM

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

Aceste blocuri funcţionale sunt astfel constituite încât urmăresc structura


logică a desfăşurării proceselor de management.

162
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).

Câmp de
Comandă
Flag1 Alarme control Flag2
ECA
erori

Cadru de comandă

Câmp de
Flag3 Informaţie control Flag4
erori

Cadru de informaţie

Câmp de
Flag1 Alarme control Flag2
erori

Cadru de supraveghere

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

Î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
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 RegStAl c NrCanal r NrRec1 NrRec2 CTRL F2

F3 Informaţie CTRL F4

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

F1 a RegStAl p NrPort CTRL F2

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

F1 a RegStAl c NrCanal CTRL F2

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

F1 a RegStAl p NrPort CTRL F2

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

F1 a RegStAl c NrPortT t e/g CTRL F2

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

F1 a RegStAl c NrRec1 NrRec2 Informaţie CTRL F2

f) Formatul cadrului de retransmisie a datelor spre PCS

F1 a RegStAl s RegStP p NrPort CTRL F2

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

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;

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

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 Reţea Nivel 3 OSI


MifC de la PCS

Legătură de Nivel 2
MC date OSI

Fig. 4.18. Organizarea funcţională a MIfC de pe 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 167
alarme
Formez masca de
citire a alarmelor

Citesc starea
alarmelor de la
porturi

NU D
Verific
RegStAlVechi ≠ A
RegStAlNoi

Întârziere 20 ms

Recitesc starea
alarmelor de la
porturi

NU DA
Verific
RegStAlVechi ≠
RegStAlNoi & dacă cele
două citiri sunt identice

Reactualizez
RegStAl

Sfârşit procesare Afişez


alarme modificarile la
DGZ şi PCS

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

Iniţializare sub
comunicaţie
168
ramă
Temporizare 30 ms

Transmit un caracter spre PCS;


Incrementez contorul transmisiilor.

Temporizare pre-
programată

DA NU
Terminat
transmisie ?

Temporizare 30 ms

Recepţionez un caracter de la ramă;


Incrementez contorul caracterelor
recepţionate.

NUN DA
U Contoar car.
Rec. ≤ 80

N D
U Timp scurs ≤ A
5 sec.

Descarc datele
Sfârşit subrutină de comunicaţie
recepţionate în buffer-ul de
cu rama
recepţie ramă

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

Iniţializare sub
verificare stare
port ECA

169
Citesc datele de la consolă
sau distant

NU DA
Intrări corecte ?

Setez portul la care


voi face testul!

Transmit şirul de test spre portul


dorit

Aştept 50 ms

NU DA

Recepţie corectă ?

Retransmit şirul de test spre


portul dorit

Aştept 100 ms

NU DA

Recepţie corectă ?

Afişează că portul Afişează că portul


funcţionează
funcţionează
CORECT
INCORECT

Reactualizează
RegStP

Sfârşit subrutină verificare


stare port

Fig. 4.21. Organigrama funcţională a subrutinei de verificare a funcţionalităţii


unui port de pe ECA

Iniţializare sub
recepţie de la
PCS

170
NU DA
Caracter nou
recepţionat ?

DA NU
Cadru în
curs de

NU DA
Caracter NU
Rec. = F2 ? Caracter
Rec. = F1 ?

DA

Resetez cadrul în curs;


Descarc car. Rec. în
Reiniţializez contoarele.
buffer-ul temporar

Incrementez Calculez caracterul de Setez indicatorul cadru în


contoar car. control CTRL curs de recepţie
Rec.

DA NU DA
NU
Contor car. Verific CTRL
Rec ≤ Max corect ?

Resetez cadrul în curs; Descarc buffer-ul


Reiniţializez contoarele. 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

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

Iniţializare
program
principal ECA

171 principalele
Testare
componente ale ECA

Lansează subrutină verificare


alarme
NU DA
Verifică recepţie
de la PCS ?

NU DA

Verifică recepţie Lansează subrutină procesare


de la consolă ? comunicaţie cu PCS

Lansează subrutină procesare


meniu

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

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:

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 b 0, 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