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

⟦8193cabe0⟧ TextFile

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

Derivation

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

TextFile

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