|
DataMuseum.dkPresents historical artifacts from the history of: RC4000/8000/9000 |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about RC4000/8000/9000 Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - download
Length: 8448 (0x2100) Types: TextFile Names: »dcsys6«
└─⟦a41ae585a⟧ Bits:30001842 SW-save af projekt 1000, Alarm-system └─⟦72244f0ef⟧ └─⟦this⟧ »dcsys6«
>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◀