DataMuseum.dk

Presents historical artifacts from the history of:

RC4000/8000/9000

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about RC4000/8000/9000

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - metrics - download

⟦ae618b891⟧ TextFile

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

Derivation

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

TextFile

>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◀