DataMuseum.dk

top - metrics - download

    Length: 8448 (0x2100)
    Types: TextFileVerbose
    Names: »dcsys6«

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

TextFileVerbose

>fo @~SP.DCSYS.6/3~@
>a1 DATABASEMODUL
Databasemodulet indeholder programmel til kommunikation med databasen.
Desuden indeholder modulet programmel til reload af netknuder.

Der p}t{nkes anvendt det databasesystem, som for tiden er under
udvikling p} JTAS.

Databasen indeholder f|lgende beskrivelser af de underliggende
knuder:

   Beskrivelse af DCs RC3502
   NC-beskrivelser
   TS-beskrivelser
   AT-beskrivelser
   VC-beskrivelser

Beskrivelsen af DCs RC3502 og NC-beskrivelserne indeholder
rutningstabeller.

Understregning af felter i den f|lgende beskrivelse betyder,
at disse felter skal sendes ud til TS ved reload.
 
>a2 TS-beskrivelse
En TS-beskrivelse indeholder:

   TS-identifikation
   VCaVCm-tabel
   AT-tabel
   VC(AT)-tabel
   VC(IT)-tabel

TS-identifikation indeholder f|lgende felter:

>ul
netadresse for TS

tidspunkt for seneste reload af TS

tidspunkt for seneste afl{sning af pakket{llere


>ne 14
>sp 12
>fg VCaVCm-tabel.

VcaVCm-tabellen indeholder samtlige vagtcentraler, som ATer p}
denne TS kan sende alarmer til, og angiver hvilke vagtcentraler
der evt. er overf|rt vagt til.

>ne 21
>sp 19
>fg AT-tabel.

AT-tabellen indeholder en indgang for hver AT tilsluttet TS. En
indgang angiver ATs alarmnetadresse, abonnentens navn og adresse, hvordan
AT fysisk er tilkoblet TS, og om AT er forsynet med parallelmodul.
Poll-feltet kan antage v{rdierne 0, 1 eller 2 med betydningen:

   0: AT polles ikke - polling er l}st fra DC
   1: AT polles
   2: AT polles ikke p.g.a. manglende forbindelse 
      til DC

Forklaring af felterne akkumuleret pakket{ller og sidste
pakket{ller findes i SP.DCSYS.3/2: Utilitymodulet.
Servicegr{nse og stop poll gr{nse er forklaret i SP.DCSYS.3.

>ne 21
>sp 19
>fg VC(AT)-tabel.

VC(AT)-tabellen indeholder en indgang for hver VC(AT) tilsluttet
TS. Hver indgang indeholder VCens alarmnetadresse, fysiske tilkobling
til TS, og om der er parallelmodul. Poll-feltet kan her antage
v{rdien 0 eller 1. 0 benyttes, n}r pollningen er oph|rt (l}st)
efter ordre fra DC, fx p.g.a. restance. Ellers bruges v{rdien 1.
Hvis vagtcentralen har overf|rt vagt til en anden VC, er v{rdien
i feltet "aktuel VCm" adressen p} denne VC. Ellers er v{rdien her 0.
Felterne akkumuleret pakket{ller, sidste pakket{ller, 
servicegr{nse og stop poll gr{nse
har samme betydning som ovenfor.

>ne 21
>sp 19
>fg VC(IT)-tabel.

VC(IT)-tabellen indeholder en indgang for hver VC(IT), der er tilsluttet
TS. En indgang indeholder VCs alarmnetadresse og fysiske tilkobling
i form af PORT- og LAM-nummer. De |vrige felter kan antage v{rdier som de
tilsvarende felter i VC(AT)-tabellen og med samme betydning.

>a2 AT-beskrivelse
Ud over den information, der findes om hver AT i TSs AT-tabel,
indeholder hver AT-beskrivelse en VC-adressektabel.

>ne 15
>sp 13
>fg VC-adressetabel.

VC-adressetabellen indeholder mindst een indgang for hver VC,
der kan modtage alarmer fra denne AT. F|rste indgang er forbeholdt
PVC. En indgang indeholder en adressekode (et tal mellem 0 og 255)
for den p}g{ldende VC. Herefter f|lger et VC-index i stedet for
som tidligere VCens alarmnetadresse. Dette index er en reference til
VCaVCm-tabellen og angiver nummeret p} den indgang heri, hvor VCens
netadresse st}r i VCa-feltet. Ved hj{lp af dette index og 
VCaVCm-tabellen kan den aktuelle modtageradresse udledes.

Feltet blokl{ngde angiver hvor mange bytes, der indg}r i en pakke
til denne modtager. Hvis samme VC |nsker at have flere blokl{ngder
til r}dighed, oprettes en indgang for hver blokl{ngde. Disse indgange
har ens VC-index, men forskellige adressekoder.
 
Sidste felt i tabellen angiver, om VCen har lov til at styre denne AT.

>a2 VC-beskrivelse
For hver VC eksisterer f|lgende oplysninger:

   information fra VC(AT)- eller VC(IT)-tabellen
   AT-adressetabel
   AT-TS-tabel
   VCa-tabel
   VCm(AT)- eller VCm(IT)-tabel
   aktuel VCe-tabel

>ne 15
>sp 13
>fg AT-adressetabel.

VCer af type IT benytter ikke feltet adressekode og f}r ikke denne
tabel ved reload.

Tabellen indeholder en indgang for hver AT, som har denne VC som PVC
eller AVC.
For en VC af type AT findes ogs} en indgang for hver AT, som
kan overf|res til denne AT.
En indgang indeholder ATens alarmnetadresse, og angiver desuden,
om denne VC er PVC eller AVC for ATen, og om ATen har parallelmodul.
Hvis VC er af type AT angives, hvilken adressekode netadressen svarer
til.

Ved vagtcentraler af type AT indeholder tabellen ogs} et felt,
der angiver hvilken PVC, der har eventuelt overf|rt kontrollen
med en AT til denne VC. Hvis ATen er flyttet hertil fra sin
>ul
PVC
, angives dette ved PVCs index i VCaVCm-tabellen, ellers
indeholder feltet et 0.

>ne 15
>sp 13
>fg AT-TS-tabel.

AT-TS-tabellen indeholder en indgang for hver TS, der har tilsluttet
ATer, som kan sende alarmer til denne VC. En s}dan indgang indeholder
alarmnetadressen p} TS og antallet af ATer, der er tilsluttet denne TS
og har denne VC som PVC. Desuden antallet af ATer, der er tilsluttet
denne TS og har denne VC som AVC, og endelig denne VCs index i den
p}g{ldende TSs VCaVCm-tabel.

Som det kan ses i figuren sendes antal AT (PVC) og antal AT (AVC)
ikke ud til TS. Dog udregnes bl.a. ved oprettelse og nedl{ggelse af
ATer for den p}g{ldende VC en "TS-type" til TS.
Udregningen foreg}r s}ledes:

   Hvis antal AT (PVC) >0, s{ttes TS-type til 1.
   Hvis antal AT (PVC) =0 og antal AT (AVC) >0,
   s{ttes TS-type til 0.

>ne 14
>sp 12
>fg VCa-tabel.

VCa-tabellen for en VC indeholder adresser p} de VCer, som kan
overf|re vagt til denne VC. Denne tabel findes ikke i VCs TS.

>ne 14
>sp 12
>fg VCm(IT)-tabel.

Hver VC af type IT har en VCm(IT)-tabel over de VCer, der kan
modtage vagt fra denne VC. Da en VC(IT) ikke kan overf|re vagt
til en VC(AT), betegner hver indgang i denne tabel en VC(IT).

>ne 14
>sp 12
>fg VCm(AT)-tabel.

Hver VC(AT) har en VCm(AT)-tabel, der indeholder en kode (tal
mellem 0 og 255) og adresse p} alle  VCer, der kan modtage vagt
fra denne VC eller f} tilsendt meddelelser herfra (herunder VCer,
der kan overf|re vagt hertil).

En indgang indeholder en netadresse og en adressekode, som denne
VC benytter i kommunikationen med den angivne VC. Desuden angiver
feltet "modtager" at

   1: den angivne VC kan modtage vagt fra denne VC.
   2: den angivne VC kan ikke modtage vagt herfra.

Indgangene kan betegne s}vel VC(AT)er som VC(IT)er.

>ne 14
>sp 12
>fg Aktuel VCe-tabel.

Der findes en aktuel VCe-tabel for hver VC. Tabellen indeholder
adresser p} de VCer, der har overf|rt vagt til denne VC, ogs}
selv om denne VC evt. senere skulle have overf|rt sin vagt.

>a1 ORGANISERING AF TABELLERNE I DATABASEN
De i f|rste kapitel omtalte tabeller organiseres i databasen
i en r{kkef|lge, der skal g|re udl{sning ved reload af en eller
flere TSer effektiv.

Dette opn}s gennem f|lgende hierarkiske struktur:

>ne 14
>sp 12
>fg Databasens struktur.

Med denne struktur vil databasens indhold se s}ledes ud:

>ne 33
>sp 31
>fg Billede af databasen.

VC(IT)ij-beskrivelse betyder VC(IT)-beskrivelse for den j'te VC(IT)
under TS nr. i. Analogt for VC(AT)ij- og ATij-beskrivelser.

Beskrivelser af alle VC(IT)-er, VC(AT)er og ATer tilknyttet
en given TS, placeres s}ledes i tilslutning til beskrivelsen af
denne TS.

Et mere detaljeret billede af informationen i databasen om en
vilk}rlig TS og dennes ATer og VCer ses i f|lgende figurer:

>ne 24
>sp 22
>fg Data for TSi med underliggende ATer og VCer.

>ne 20
>sp 18
>fg VC(IT)i-tabel inkl. VC(IT)ij-beskrivelser.

>ne 20
>sp 18
>fg VC(AT)i-tabel inkl. VC(AT)ij-beskrivelser.

>ne 20
>sp 18
>fg ATi-tabel inkl. ATij-beskrivelser.

«eof»