DataMuseum.dk

Presents historical artifacts from the history of:

RC3500

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

See our Wiki for more about RC3500

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - metrics - download

⟦8193cabe0⟧ TextFileVerbose

    Length: 7680 (0x1e00)
    Types: TextFileVerbose
    Names: »dcsys8«

Derivation

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

TextFileVerbose

>fo@~SP.DCSYS.8/2~@
>a1 NETINTERFACE I RC8000
Dette modul udg|r interfacet mellem RC8000 og nettet.

Meddelelser fra RC8000 til nettet pakkes her til det kr{vede
format med modtageradresse, afsenderadresse (- DCs alarmnetadresse),
operationskode og datadel. Desuden oprettes en logmeddelelse.

Modulet udpakker meddelelser til RC8000 fra nettet. Det checkes,
at modtageradressen er lig med DCs alarmnetadresse. Desuden afl{ses
operationskoden for at afg|re hvilket modul, der skal behandle
meddelelsen.

Alle meddelelser, der modtages i netinterface fra nettet, skal
logges. Det afg|res ud fra operationskode, om meddelelsen er en
logmeddelelse (dvs. at datadelen omfatter den oprindelige meddelelse
og et tidspunkt), s}ledes at kun datadelen skal logges, eller om hele
meddelelsen skal afleveres bl.a. til logmodulet.

Operationskode 0.0:

Dette er en logmeddelelse, s}
>ul
datadelen
skal afleveres til logmodulet.

Det er muligt, at meddelelsen ogs} skal benyttes til en opdatering
af databasen i DC. Dette kan afg|res ud fra operationskode, afsender
og modtager i den oprindelige meddelelse (alts} i logmeddelelsens
datadel).

Det er klart, at operationskoden har betydning ved denne afg|relse.
At afsender/modtager har betydning skyldes, at behandlingen i DC
afh{nger af, om afsender og modtager h|rer ind under den p}g{ldende
DC eller om en af disse h|rer til under en anden DC.

>ne 34
>ex Opdatering ud fra logmeddelelse.
>sp 16
>fg 5.2-logmeddelelse.
>sp 16
>fg 5.2-logmeddelelser.

Ved afsendelse af en 5.2-meddelelse (meddelelse om vagtflytning) fra
VC1 til VC2 skal aktuel VCm opdateres hos VC1 (i VC1's TS og DC)
og aktuel VCe-tabel skal opdateres hos VC2 (i VC2's TS og DC). Hvis
VC1 og VC2 ligger under samme DC, skal logmeddelelsen for 5.2
(log 1) resultere i {ndring af begge tabeller i DC. Hvis VC1
og VC2 ligger under to forskellige DCer (DC1 og DC2), sendes
en logmeddelelse til hver DC. Den ene logmeddelelse (log 2)
resulterer i {ndring af VC1s aktuel VCm i DC1, og den anden
(log 3) i {ndring af VC2s aktuel VCe-tabel i DC2.

I netinterfacet betragtes imidlertid kun operationskoden. Hvis
denne i nogle tilf{lde vil give anledning til opdatering af 
databasen, v{lger netinterfacet altid at aflevere en kopi af den 
oprindelige meddelelse til det modul, som skal foretage en evt.
opdatering, uanset hvilken DC afsender/modtager h|rer ind under.
Dvs. at det modul, som meddelelsen afleveres til afg|r endeligt,
om der skal foretages en opdatering i databasen og i s} fald
hvilken.

Andre operationskoder:

Meddelelser med operationskode forskellig fra 0.0 skal, foruden
den |vrige behandling, logges p.g.a. kravet om, at alle meddelelser
skal logges. Derfor afleveres en kopi af
>ul
hele meddelelsen
til logmodulet. Afsenderen af en s}dan meddelelse inds{tter 
tidspunkt for afsendelse forrest i datadelen til brug ved denne
logning. Operationskoden er afg|rende for, hvilket andet modul
meddelelsen (p} n{r tidspunktet) afleveres til. F|r aflevering
af meddelelsen til logmodulet foretages en ompakning, idet
tidspunktet skal st} forrest (alts} ogs} foran modtager og
afsenderadresse).

Meddelelser til DC med operationskode 0.0 er s}ledes logmeddelelser for meddelelser,
hvis modtageradresse er forskellig fra DCs adresse (= logmeddelelsens
modtageradresse). Af disse meddelelser logges datadelen.

Meddelelser til DC med andre operationskoder er ikke logmeddelelser,
men skal alligevel logges. Der sendes alts} ikke en s{rskilt 
logmeddelelse til DC. Derfor tages en kopi af hele meddelelsen til
logmodulet. Dvs. at kopiering til logform}l af meddelelser
>ul
til
DC selv foreg}r i netinterfacet i DC og ikke hos afsenderen af meddelelsen
som i de fleste andre tilf{lde.

Ved logning af krypteringsmeddelelser (10.8 og 10.9) g{lder specielt,
at krypteringsn|glen fjernes fra datadelen inden udskrivning p} logfil.

Her f|lger en liste over operationskoder og hvilke moduler, som
meddelelser med disse operationskoder skal afleveres til:
  
Alle meddelelser afleveres til LOG-modulet. De nedenforst}ende
meddelelsestyper afleveres herudover til et andet modul.
  
>ne 6
 Opkode  Modul Navn

 0.0-5.2  UTIL Logmeddelelse
 0.0-5.5  UTIL -
 0.0-5.6  UTIL -
 0.0-5.10 UTIL -
 
 0.0-6.10 UTIL -

 0.0-9.4  UTIL -
 0.0-9.6  UTIL -
 0.0-9.7  UTIL -
 
 0.0-10.0 UTIL -
 0.0-10.6 UTIL -

 2.0      EH   DC-udfald
 2.1      EH   DC-genoprettelse
 2.2      EH   NC-udfald
 2.3      EH   NC-genoprettelse
 2.4      EH   TS-udfald
 2.5      EH   TS-genoprettelse
 2.6      EH   VC-moduludfald
 2.7      EH   VC-genoprettelse
 2.8      EH   AT-moduludfald
 2.9      EH   AT-modulgenoprettelse
 
 3.1      EH   Liniealarm
 3.2      EH   Statusalarm
 3.4      EH   Servicealarm
 3.5      EH   Stop-poll-alarm
 
>ne 9
 5.1      UTIL Kvittering for anmodning om vagt-
               flytning
 5.3      UTIL Kvittering for vagtreturnering
 5.5      UTIL Kvittering for anmodning om vagt-
               returnering
 5.7      UTIL Kvittering for vagtreturnering
 5.9      UTIL Kvittering for ordre om foretag
               vagtreturnering
 5.11     UTIL Kvittering for videreflytning
 
 6.1      UTIL Kvittering for oprettelse af AT
 6.5      UTIL PVC-tilladelse til stop/start poll
 6.7      UTIL Kvittering for anmodning om
               nedl{ggelse af AT
 6.9      UTIL Kvittering for nedl{ggelse af AT
 
 7.1      UTIL Kvittering for oprettelse af VC
 7.3      UTIL Kvittering for anmodning om 
               nedl{ggelse af VC
 7.5      OPT  Kvittering for nedl{ggelse af VC
 
>ne 2
 8.1      OPT  Kvittering for intern test 1
 8.3      OPT  Kvittering for intern test 2
 
>ne 10
 9.1      OPT  Kvittering for ordre om stop/start
               polling
 9.2      OPT  Kontrol af AT-VC-forbindelse
 9.5      UTIL Kvittering for anmodning om
               opdatering af VCm-tabel i DC
 9.7      UTIL Kvittering for anmodning om
               opdatering af VCa-tabel i DC
 9.8      OPT  Generel meddelelse
 9.10     UTIL Afsend AT-beskrivelse
  
>ne 8
 10.1     UTIL Kvittering for opdatering af 
               VC-adressetabel
 10.3     UTIL Kvittering for opdatering af 
               AT-adressetabel
 10.4     UTIL Opdatering af AT-TS-tabel
 10.5     UTIL Kvittering for opdatering af 
               AT-TS-tabel
 10.7     UTIL Kvittering for opdatering af  
               VCm(AT)- eller VCm(IT)-tabel
 10.9     UTIL Kvittering for opdatering af
               krypteringstabel

 11.3     OPT  Kvittering for afl{sning af
               transmissionsfejlt{ller
 11.5     UTIL Kvittering for afl{sning af
               pakket{ller
 11.7     UTIL Kvittering for opdatering af
               servicegr{nse
 11.9     EH   Kvittering for afl{sning af
               aktuel VCm
 11.11    UTIL Kvittering for opdatering af
               stop-poll-gr{nse
 11.13    UTIL Kvittering for opdatering af
               max-succ-lin-fejl



Ved pakning af meddelelser fra DC til nettet, skal netinterfacet
kende modtageradresse, operationskode og datadel. Afsenderadresse
er altid DC's egen netadresse. Pakken afleveres til link-driver.
Meddelelser fra DC til andre netknuder skal logges. Netinterface
s|rger for at afl{se det aktuelle tidspunkt for aflevering af
hver meddelelse til link-driver, og afleverer herefter en kopi af
tidspunkt + meddelelsen til logmodulet.
«eof»