DataMuseum.dk

top - metrics - download

    Length: 9984 (0x2700)
    Types: TextFile
    Names: »dcsys5«

└─⟦a41ae585a⟧ Bits:30001842 SW-save af projekt 1000, Alarm-system
    └─⟦72244f0ef⟧ 
        └─⟦this⟧ »dcsys5« 

TextFile

>fo @üSP.DCSYS.5/3ü@
>a1 INDLEDNING.
Errorhandler indeholder programmel til behandling af fejlmeddelelser og skal desuden være
i stand til at reloade underliggende netknuder efter break-down.

Ved reload af underliggende netknuder hentes den nødvendige information hertil fra databasen, hvorefter den sendes
til den pågældende netknude.

Fejlmeldinger til DC afleveres i errorhandler (EH), der så sørger for den nødvendige behandling.

>ne5
Fejl kan opdeles i følgende kategorier:

  1)  Fejl mellem AT og TS
  2)  Fejl mellem VC og TS
  3)  Fejl på nettet
  4)  Fejl i software

Forkortelsen "EH" vil blive brugt for ERRORHANDLER-MODULET.

>a1 FEJL MELLEM AT OG TS.
Fejl mellem en AT og en TS opdages i DCs EH ved, at der kommer en liniealarm,
en servicealarm eller en stop-poll-alarm. Fejl i AT eller AU resulterer i en
statusalarm.

>a2 Liniealarm.
En liniealarm optræder, når der har været 
et bestemt antal (max-succ-lin-fejl) transmissionsfejl i træk.
TS har samtidig sendt en liniealarm til PVC. I datadelen angives, om
den sidste af disse transmissionsfejl var en timeout(0) eller anden
fejl(1). En efterfølgende korrekt transmission giver anledning til
afmelding af liniealarmen (samme meddelelsestype - datadel = 2).

>a2 Servicealarm.
Hvis transmissionskvaliteten falder under et givet niveau
skal der afgives alarm.
Dette sker efter følgende princip:

>ne22
>sp20
>fg Overvågning af transmissionsfejl.

For hver korrekt transmission tælles tælleren et skridt ned
og for hver transmissionsfejl 1/a skridt op. 
Der kan aldrig tælles under 0.
Ved c/a (=servicegrænse) afgives "servicealarm" til DC:

  Modtageradresse = DC
  Afsenderadresse = AT- eller VC-CONNECTOR
  Operationskode  = 3.4
  Datadel         = 0/1   (0: på vej ned)
                          (1: på vej op )

Datadelen i en servicealarm kan indeholde værdierne 0
eller 1. 1 angiver at transmissionsfejltæller er kommet op
på eller over servicegrænsen. 0 angiver, at transmissionsfejltæller
er kommet ned under grænsen.
Servicealarm sendes således een gang hver gang grænsen passeres.

Servicealarmer afleveres i ERRORHANDLER. Desuden resulterer 
servicealarmen i een af følgende udskrifter på konsollen (afhængig
af datadelen):

  servicealarm fra "AT eller VC"

eller

  afmelding af servicealarm fra AT ellerVC

Ved udskrivning af servicealarm skal operatøren tilkalde en 
tekniker.

>a2 Overvågning for transmissionsalarm.
Operatøren kan foretage en manuel overvågning af tælleren gennem
kommandoen:

 transmissionsfejltæller : "AT eller VC";

der oversættes til

>ne5
  Modtageradresse = AT eller VC
  Afsenderadresse = DC
  Operationskode  = 11.2
  Datadel         = tom

Fra AT- eller VC-CONNECTOR svares med en kvittering for
aflæsning af transmissionsfejltæller:

  Modtageradresse = DC
  Afsenderadresse = AT eller VC
  Operationskode  = 11.3
  datadel         = transmissionsfejltæller

I DC afleveres meddelelsen til OPT, der udskriver svaret.
Operatøren kan desuden foretage en intern test.

>a3 Standsning af poll.
Hvis transmissionsfejltælleren når op på stop-poll-grænsen bør den
pågældende AT/VC ikke længere polles. EH giver operatøren besked om dette,
hvorefter denne bør starte stop-poll proceduren. Pollning stoppes altså
ikke automatisk.

Efter fejlretning og genoptagelse af pollning kan transmissionsfejltælleren
igen komme under stop-poll-grænsen. Når dette sker sendes en
afmelding af stop-poll-alarm.

Formatet for en stop-poll-alarm og afmelding af denne er det samme
som benyttes ved servicealarm. Dog er operationskoden 3.5.

Konsoludskrifterne har formatet

  stop-poll-alarm fra "AT eller VC"

og

  afmelding af stop-poll-alarm fra "AT eller VC"

>a2 Statusalarm.
En statusfejl i AU eller AT giver anledning til afsendelse af statusalarm såvel
til DC som til primær VC.

EH reagerer på alarmen ved at udskrive denne på operatørkonsollen i DC,
hvorved en del af behandlingen overlades til en operatør.

Formatet for skærmudskriften er:

  statusalarm fra "AT eller VC": "statusbyte"


>a1 FEJL MELLEM VC OG TS.
Fejl mellem en VC og en TS opdages i DCs EH på en af følgende måder, enten ved at der kommer en
liniealarm (p.g.a. max-succ-lin-fejl transmissionsfejl i træk),  
en servicealarm, en stop-poll-alarm 
eller hvis VC er af type AT, kan der komme statusalarm
(efter en STATUS-meddelelse fra AT til TS).

>a2 Udskrift af alarmer.
EH sørger for udskrivning af disse alarmer på operatørkonsollen i DC, hvor operatøren så skal sørge for den
videre behandling af fejlen.

Formatet er som beskrevet i forrige kapitel.

>a2 Spooling af alarmer
Desuden modtager EH de alarmer, som den pågældende VC ikke selv er i stand til at modtage.
EH udskriver ikke disse alarmer på hovedkonsollen.

Alarmerne gemmes (spooles) til evt. senere udsendelse til oprindelig modtager.

>a2 Operatøraktion.
Operatøren på DC kan nu vælge gennem en kommando til OPT enten at overføre den pågældende VCs
vagt til en anden VC, eller at VCs abonnenter ikke længere skal polles.

I første tilfælde giver OPT utilitymodulet ordre til at udføre en 
vagtoverførsel (se SP.DCSYS.3).
I andet tilfælde giver OPT besked til EH om ophør af poll.

>a3 Standsning af poll.
Ved standsning af poll, skal EH sende en meddelelse herom til alle TSer
med abonnenter, der har denne VC som PVC. Meddelelsen har følgende format:

>ne 4
  modtageradresse = AT-handler i en TS
  Afsenderadresse = DCs adresse
  Operationskode  = 9.0
  Datadel         = 0 for stop-poll, 1 for start-poll
                    VC-adresse

Herefter sørger TSerne selv for at ophøre med at polle de pågældende ATer
og sende kvittering tilbage til DC.
Kvitteringen sendes med meddelelsestype 9.1.

>a1 FEJL PÅ NETTET.
Ved fejl på alarmnettet, så en logisk forbindelse afbrydes,
vil den "opdagende" knude underrette såvel den overliggende
knude, som alle de af dens underliggende knuder, den har 
forbindelse til. Dette sker i form af en broadcast-meddelelse.

>ne6
Formatet for en sådan er:

  Modtageradresse = "modt."
  Afsenderadresse = "opdagende knude"
  Operationskode  = 2.X   (se neden for)
  Datadel         = "udfaldne knude"

Når en knude får denne meddelelse
>ul
oppefra
i nettet sendes den
videre til alle underliggende knuder.
Kommer den
>ul
nedefra
sendes den til såvel den overliggende knude som til alle
underliggende knuder (undtagen den, som den kom fra).

Knuden på DC sender desuden meddelelsen videre til de andre
DC'er, samt til EH i sin egen DC.

X'et i meddelelsestypen kan antage følgende værdier:

>ne12
    kode    betydning
     0      DC-udfald
     1      DC genoprettelse
     2      NC-udfald
     3      NC genoprettelse
     4      TS-udfald
     5      TS genoprettelse
     6      VC-moduludfald
     7      VC-moduloprettelse
     8      AT-moduludfald
     9      AT-modulgenoprettelse
  10-15     ikke anvendt



TSerne under bruddet sørger for at underrette de underliggende VCer om fejlen, og holder op
med at polle de ATer, der ikke har forbindelse med hverken PVC eller DC.

EH udskriver fejlen på hovedkonsollen i DC.

Formatet er:

 alarmnetudfald: "udfaldne knude"


Operatøren i DC kan vælge mellem følgende muligheder:

>ne2
  1)  EH modtager alarmer fra ATer, der har forbindelse
      til DC, men ikke til den VC, der skulle modtage
      alarmen.
 
>ne2
  2)  Pollning standses af ATer, hvis PVC er involveret
      i bruddet.

>ne2
  3)  Vagtflytning foretages for VCer, der har mistet
      forbindelsen til en del af deres ATer.

Indtil operatøren har meddelt andet (dvs. valgt 2 eller 3), sendes alarmer fra ATer 
sendes alarmer fra ATer, som har forbindelse til DC men ikke til VC,
til EH, der spooler dem (1).

ATer, som ikke har forbindelse til hverken PVC eller DC, kan ikke
hjælpes gennem en vagtflytning, da kun PVC og DC har myndighed til
at udføre vagtflytning. Derfor standses pollning af disse automatisk
fra TSen.
Det har den bivirkning, at alarmer til AVCer for disse ATer heller ikke kan komme frem.

>ne27
>a2 Brud på forbindelsen fra AT til både DC og PVC

>sp18
>fg Alarmnetudfald af TS1

TS1 ophører med at polle AT, da alarmer til PVC ikke kan komme igennem hverken til PVC eller DC.
Som bivirkning ses, at alarmer fra AT til AVC ikke kommer igennem, selv om forbindelsen her
er i orden.

>ne 25
>a2 Brud på forbindelsen fra AT til PVC

>sp18
>fg Alarmnetudfald af TS1

AT1 og AT2 har VC1 som PVC. Efter alarmnetudfaldet af TS1, sender operatøren ved DC
kommandoen:

  overfør vagt: afsender = "VC1", modtager = "VC2";

til OPT, hvor den fortolkes og afleveres til UTIL.

UTIL sørger for at overføre vagten fra VC1 til VC2. Dette registreres i VCaVCm-tabellen i TS2,
men ikke i TS1 p.g.a. bruddet. Herefter vil alarmer fra AT1 til PVC stadig blive sendt til VC1,
mens alarmer fra AT2 til PVC i stedet bliver sendt til VC2.

>a2 Efter udbedring af fejlen.
Når fejlen er udbedret rundsendes meddelelse herom på
samme måde som ved fejlens opståen (meddelelsen udbredes til
alle knuder "som ringe i vandet").

Formatet er det samme som ved meddelelsen om fejlens opståen.

Meddelelsen udskrives af EH på hovedkonsollen:

  alarmnetudbedring: "knude"

Herefter skal VCaVCm-tabellerne i TSerne gøres konsistente, idet vagtoverførsler, der er
foretaget, mens der var brud kun gælder enten uden for eller under bruddet.

Situationen
>ul
under
det tidligere brud skal nu gælde overalt i nettet.

Derfor skal EH automatisk igangsætte vagtreturnering for de VCer,
som der p.g.a. alarmnetudfaldet blev foretaget vagtflytning for fra DC
(se SP.DCSYS.3).

▶EOF◀