|
DataMuseum.dkPresents historical artifacts from the history of: RC3500 |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about RC3500 Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - download
Length: 29952 (0x7500)
Types: TextFileVerbose
Names: »dcsys0«
└─⟦a41ae585a⟧ Bits:30001842 SW-save af projekt 1000, Alarm-system
└─⟦72244f0ef⟧
└─⟦this⟧ »dcsys0«
>bl
>a1 OPDELING AF DC I MODULER
De funktioner, som et distriktscenter skal udf|re, er beskrevet i AL.RC.8: Distriktscentrets funktioner. I figur 1
vises de moduler, som distriktscentret opdeles i for at udf|re de |nskede funktioner.
Moduler i RC8000:
- Operat|rmodel OPT
- Utilitymodul UTIL
- Logmodul LOG
- Errorhandler EH
- Databasemodul DB
- Netinterface NI
- Basisprogrammel BASIS
- FPA-driver (Front end Processor Adapter)
- Link-driver
- Disc-driver
Moduler i RC3502:
- Netprogrammel NETP
- FPA-driver
- Net control process NCP
- LAM-driver (Low speed Asynchronous Multiplexer)
- TTY-driver
Moduler i RC8302:
- FPA-driver
- NCP
- MT-driver
- LP-driver
- TTY-driver
>ne 50
>sp 48
>fg Modulopdeling af DC.
De moduler, der ikke er standard, beskrives i de n{ste to kapitler.
>np
>a1 MODULER I RC8000
I dette kapitel beskrives de moduler, som en RC8000 i et distriktscenter skal indeholde for at
udf|re de |nskede funktioner.
Funktionerne er i det v{sentlige som beskrevet i AL.RC.8: Distriktscentrets funktioner. Dog er der
opst}et enkelte {ndringer i forhold til dette skrift, bl.a. ang. klartekster, som er flyttet
fra distrikstscentret ud til de enkelte vagtcentraler.
De moduler i RC8000, som beskrives her, er f|lgende:
- Operat|rmodul OPT
- Utilitymodul UTIL
- Logmodul LOG
- Errorhandler EH
- Databasemodul DB
- Netinterface NI
>a2 Operat|rmodul.
Operat|rmodulet OPT har til opgave at fortolke og behandle kommandoer fra operat|rkonsollen i
distriktscentret.
Operat|rerne afgiver kommandoer interaktivt i MML (Man Machine Language). Syntaksen for disse
kommandoer f|lger CCITTs rekommendationer. For at kunne behandle kommandoerne har OPT
forbindelse til de |vrige moduler i RC8000.
De kommandoer som kan afgives til OPT, kan opdeles i f|lgende kategorier:
- Utilitykommandoer
- Logkommandoer
- Fejlkommandoer
Utilitykommandoer benyttes ved vagtoverf|rsel, til- og afmelding af ATer, VCer og netknuder og
desuden ved test af ATer internt og eksternt.
Logkommandoer benyttes til overv}gning af logningen, listning af
bestemte delm{ngder af logfilen, f.eks. alle meddelelser
til/fra en bestemt VC i en bestemt periode, og desuden til statistikker.
Fejlkommandoer omfatter de reaktioner, som operat|ren kan give efter at have modtaget
fejlmeddelelser p} konsollen.
Kommandoerne beskrives i de f|lgende afsnit.
>a2 Utilitymodul.
Utilitymodulet aktiveres enten gennem MML-kommandoer fra operat|rkonsollen via operat|rmodulet
eller fra terminaler p} ekspeditionskontorerne.
Modulet udf|rer f|lgende funktioner:
- Vagtoverf|rsler
- Til-/afmelding af abonnenter
- Til-/afmelding af vagtcentraler
- Til-/afmelding af netknuder
- Test af ATer internt og eksternt
- L|bende {ndringer
>a3 Vagtoverf|rsel.
En vagtoverf|rsel kan initieres enten af den VC, der for tiden har ansvaret for de ATer,
der skal flyttes, eller af operat|ren i DC.
N}r en vagtoverf|rsel initieres af en VC, er det denne VCs TS, der styrer overf|rslen,
ellers er det DC, der styrer overf|rslen.
En vagtoverf|rsel initieret fra DC foreg}r p} f|lgende m}de:
Operat|ren i DC sender denne MML-kommando til OPT:
Vagtoverf|rsel: Afsender = "VCa", modtager = "VCm";
Kommandoen fortolkes af OPT og afleveres til utilitymodulet.
I utilitymodulet sker herefter f|lgende:
Der foretages opslag i databasen under afsender-VCens VC-beskrivelse. Det checkes, at
modtager-VC er indeholdt i denne VC-beskrivelses VCm-kartotek (over lovlige flytninger).
Hvis modtager-VC ikke er med i kartoteket, sender UTIL f|lgende meddelelse til operat|ren i DC:
Ulovlig vagtoverf|rsel
Ellers sendes en meddelelse om overf|rslen fra UTIL til modtager-VC (VCm), der forventes at
kvittere herfor.
Meddelelse om overf|rsel:
- Modtager: VCm-adresse
- Afsender: DC-adresse
- Operationskode: "Anmodning om vagtoverf|rsel"
- Datadel: VCa-adresse
Kvittering, hvis modtager-VC accepterer overf|rslen:
- Modtager: DC-adresse
- Afsender: VCm-adresse
- Operationskode: "Accept af vagtoverf|rsel"
- Datadel: VCa-adresse
Ved accept gennemf|res overf|rslen, ellers gives besked til operat|ren om afslaget:
Vagtoverf|rsel ikke kvitteret af modtager
Overf|rslen udf|res i to trin som beskrevet i SP.TS.1:
1) VCas egen abonnentgruppe overf|res til VCm.
2) De |vrige abonnentgrupper, der for tiden er tilknyttet
VCa, overf|res til VCm.
Abonnentgrupperne under punkt 2 kan afl{ses i TSa-beskrivelsens VCa-VCm-kartotek over aktuelle flytninger (i DC).
Det drejer sig om de indgange, hvor VCa optr{der p} h|jre side, f.eks.
VCe -> VCa
F|rst overf|res VCas egen abonnentgruppe:
UTIL sender meddelelser til VCms TS (TSm) og til de af f|lgende TSer, der er forbindelse med:
TSa (VCas TS) og alle TSer, der er med i VCas AT-TS-kartotek.
Meddelelserne har dette indhold:
- Modtager: TS-adresse
- Afsender: DC-adresse
- Operationskode: "Udf|r vagtoverf|rsel"
- Datadel: VCa-adresse
VCm-adresse
Det er hensigten, at de enkelte TSer nu skal opdatere deres VCa-VCm-kartotek,
s} det indeholder
VCa -> VCm
og ikke andre indgange med VCa p} venstre side.
En s}dan meddelelse skal ogs} sendes til de p}g{ldende TSers DCer,
hvor den skal resultere i en tilsvarende {ndring i VCa-VCm-kartoteket.
For hver af de i punkt 2 omtalte abonnentgrupper f.eks. VCes abonnentgruppe udf|res f|lgende:
F|rst sendes besked til TSa (hvis forbindelsen er i orden) om at fjerne sin indgang
VCe -> VCa
i VCa-VCm-kartoteket. Samme {ndring skal foretages i kopien af VCa-VCm-kartoteket i TSa-beskrivelsen
i DC.
Meddelelsen:
- Modtager: TS-adresse
- Afsender: DC-adresse
- Operationskode: "Udf|r vagtoverf|rsel"
- Datadel: VCe-adresse
VCm-adresse
sendes ud med modtagerne TSe, TSm og TSerne i VCe-beskrivelsens AT-TS-kartotek.
Samme meddelelse skal sendes til involverede DCer.
Det kr{ves, at i det mindste forbindelsen fra DC til TSm er i orden.
Herefter sender UTIL meddelelse til TSm og TSa om, at vagtoverf|rslen er foretaget.
UTIL vil nu udskrive p} hovedkonsollen:
Vagtoverf|rsel foretaget fra "VCa-adresse" til "VCm-adresse".
>a3 Til-/afmelding af abonnenter.
Til- og afmelding af abonnenter foretages p} ekspeditionskontorer via en formatorienteret sk{rm.
Tilmelding af en abonnent foreg}r ikke som tidligere beskrevet i to trin, men udf|res p} en gang.
Tilmeldingen starter med en tilmeldingskommando:
Tilmeld AT;
hvorefter der svares med et sk{rmbillede til oprettelse af en abonnent. Dette
sk{rmbillede indeholder felter til angivelse af abonnentens navn og adresse, netadresse for ATen,
prim{r vagtcentral og alternative vagtcentraler.
Eksempel:
Tilmelding af AT
Navn: Peter Jensen
Adresse: \stergade 40
Netadresse: 03 17 23 02345
PVC: 01 - 02 17 22 00014
AVC: 02 - 01 04 16 00018
02 - 01 04 16 00017
Oplysningerne afleveres
til utilitymodulet, der bruger dem til {ndringer i DCs database.
Der foretages {ndringer i TS-beskrivelsen i DC for den TS, som den nye AT tilsluttes, idet
AT-adressen tilf|jes i AT-kartoteket over tilknyttede ATer og i routningstabellen for TSen.
Desuden oprettes en AT-beskrivelse for den nye AT. Denne forsynes med
abonnentens navn og adresse, netadressen for ATen,
netadresse og kode for prim{r VC og aktuel VC og desuden et VC-adressekartotek med netadresse
og kode for prim{r og alternative VCer. UTIL v{lger selv disse koder.
Herefter sender UTIL nogle af oplysningerne til den TS, som den nye AT tilsluttes, og efter oprettelsen
er foretaget her, kvitteres til DCs utilitymodul.
Eksempel p} meddelelse til TS:
- Modtager: 03 17 23 00000 ATs TS
- Afsender: 03 00 00 00000 ATs DC
- Operationskode: "Tilmeld AT"
- Datadel: 03 17 23 12345 netadresse AT
01 kode PVC
02 17 22 00014 adresse PVC
02 kode AVC
01 04 16 00018 adresse AVC
03 kode AVC
01 04 16 00017 adresse AVC
Nu sender UTIL i ATs DC oplysninger om oprettelse til UTIL i prim{r og alternative VCers DCer,
medmindre disse er identiske.
Eksempel:
- Modtager: 02 00 00 00000 PVCs DC
- Afsender: 03 00 00 00000 ATs DC
- Operationskode: "Tilmeld AT til PVC"
- Datadel: 03 17 23 12345 netadresse AT
02 17 22 00014 netadresse PVC
Her benyttes oplysningerne til opdatering af VC-beskrivelsens kartoteker over abonnenter og
abonnent-TSer. Hvis den p}g{ldende VC er af type AT skal dens adressekartotek udvides med
den nye ATs adresse og en kode svarende hertil.
UTIL i VCs DC sender nu oplysninger til VCs TS om oprettelsen, hvorefter TS foretager sig det forn|dne,
og sender en kvittering tilbage til UTIL i VCs DC, n}r oprettelsen er foretaget.
Eksempel:
- Modtager: 02 17 22 00000 VCs TS
- Afsender: 02 00 00 00000 VCs DC
- Operationskode: "Tilmeld AT til PVC"
- Datadel: 03 17 23 12345 AT
02 17 22 00012 PVC
57 evt. kode for AT, hvis
PVC er AT-VC.
UTIL i VCs DC sender herefter en meddelelse til UTIL i ATs DC, der udskriver p}
hovedkonsollen, at opgaven er udf|rt.
Afmelding af en abonnent foretages ogs} p} ekspeditionskontorerne, men foruds{tter en meddelelse fra
abonnentens PVC om afmeldingen.
Meddelelsen fra PVC resulterer i inds{ttelse af AT-adressen i tabellen "AT-afmelding" i DCs database:
>ne8
>sp8
Fra en terminal p} DC indtastes:
Afmeld AT: "AT-adresse";
UTIL-modulet checker, om denne AT-adresse er indeholdt i tabellen AT-afmelding. Hvis dette ikke
er tilf{ldet, m} afmeldingen ikke udf|res, og der udskrives p} terminalen:
AT-afmelding ikke tilladt
Hvis AT-adressen er indeholdt i tabellen, skal afmeldingen foretages. F|rst sletter UTIL den p}g{ldende
adresse i tabellen AT-afmelding. Herefter sendes meddelelse om afmeldingen til ATs TS, der kvitterer,
n}r afmeldingen her er foretaget.
Fra en terminal indtastes:
Afmeld AT: "AT-adresse";
UTIL sender meddelelse om afmeldingen til ATs TS, der kvitterer, n}r afmeldingen her er
foretaget.
Eksempel:
- Modtager: 03 17 23 00000 ATs TS
- Afsender: 03 00 00 00000 ATs DC
- Operationskode: "Afmeld AT"
- Datadel: 03 17 23 12345 AT
UTIL udf|rer afmelding i DC ved at fjerne AT fra TS-beskrivelsens kartotek over ATer og VCer.
Desuden slettes ATens AT-beskrivelse fra databasen.
UTIL sender nu meddelelse til de DCer, som ATens prim{re og alternative VCer er tilsluttede.
Eksempel:
- Modtager: 02 00 00 00000 PVCs DC
- Afsender: 03 00 00 00000 ATs DC
- Operationskode: "Afmeld AT"
- Datadel: 03 17 23 12345 AT
02 17 22 00014 PVC
I hver af disse DCer sendes nu meddelelse til VCernes TSer om afmeldingen. TSerne udf|rer
deres afmelding og kvitterer herefter til DCerne.
Nu foretages afmelding i DC ved at fjerne AT fra VC-beskrivelsens abonnentkartotek,
opdatere abonnent-TS-kartoteket, og hvis VC er af type AT, s} fjernes ogs} ATs kode og netadresse
fra adressekartoteket. S} sendes kvittering for afmelding til ATs DC.
N}r ATs DC har modtaget alle kvitteringer, udskriver UTIL p} terminalen:
Afmelding foretaget p} "AT-adresse"
>a3 Til-/afmelding af vagtcentraler.
Tilmelding af en vagtcentral foretages ligeledes fra ekspeditionskontorerne via en formatorienteret
sk{rm,
mens afmelding af en vagtcentral skal foretages fra operat|rkonsollen.
Tilmelding starter med indtastning af kommandoen:
Tilmeld VC;
der besvares med et sk{rmbillede til oprettelse af en vagtcentral.
Sk{rmbilledet indeholder felter til angivelse af vagtcentralens navn og adresse, netadressen
og hvilke vagtcentraler, der kan overf|res vagt til og fra.
Eksempel:
Tilmelding af vagtcentral:
Navn: ALARMETTA
Adresse: N|rreport 38
Netadresse: 02 17 22 00014
Type: IT
Vagtoverf|rsel til: 02 17 22 00013
Vagtoverf|rsel fra: 01 04 16 00018
Efter indtastningen benytter utilitymodulet oplysningerne til {ndringer i DCs TS-beskrivelse
for den TS, som VCen tilsluttes, op til oprettelse af en VC-beskrivelse.
Oplysningerne tilf|jes i TS-beskrivelsens kartotek over tilsluttede ATer og VCer. Desuden
oprettes i DC en VC-beskrivelse for den nye VC med oplysninger om VCens netadresse, type,
et VCa- og et VCm-kartotek (over lovlige flytninger)
og et kartotek over lovlige flytninger. Disse kartoteker indeholder
netadressen p} VCer, der m} overf|re vagt fra hhv til den nye VC.
De VCer, som den nye VC m} overf|re sin vagt til/f} overf|rt vagt fra, skal informeres om dette.
Derfor sendes meddelelse herom til disse VCer. Hvis de accepterer (og s}ledes tilf|jer den nye VC
i deres VCa- eller VCm-kartotek), sendes kvittering tilbage til DC og operat|ren,
ellers sendes et afslag.
Herefter sender utilitymodulet besked til den nye VCs TS om oprettelsen, f.eks.:
- Modtager: 02 17 22 00000 ny VCs TS
- Afsender: 02 00 00 00000 ny VCs DC
- Operationskode: "Tilmeld VC"
- Datadel: 02 17 22 0000 4 ny VC
02 17 22 00013 VCm-kartotek
I TS foretages lignende {ndringer, og n}r oprettelsen er foretaget i TS, kvitteres til DC,
der igen kvitterer til operat|ren:
Eksempel:
- Modtager: 02 00 00 00000 VCs DC
- Afsender: 02 17 22 00000 VCs TS
- Operationskode: "VC tilmeldt"
- Datadel: 02 17 22 00004 VC
og
tilmelding foretaget p} "VC-adresse".
Afmelding af en vagtcentral sker efter ordre fra hovedkonsollen:
Afmeld VC: "VC-adresse";
Kun personer med speciel tilladelse kan udstede denne ordre.
Det skal sikres, at vagtcentralen ikke indg}r i VCa-VCm-kartoteket, d.v.s. at der ikke er
overf|rt vagt fra eller til denne VC.
Utilitymodulet starter med at sende besked om afmeldingen til den p}g{ldende vagtcentral.
Der findes en fortegnelse over VCens abonnenter i VC-beskrivelsens abonnentkartotek. Herudfra
foretages afmelding af alle abonnenter, der har denne VC som PVC. Hos abonnenter, der har
denne VC som AVC, skal VCen og dennes kode og blokl{ngde fjernes fra deres AT-adressekartotek.
Denne {ndring skal foretages b}de i ATs TS og ATs DC.
S} gives besked om afmeldingen til alle vagtcentraler i VCa- og VCm-kartoteket for denne VC,
hvorefter disse VCers VCa- og VCm-kartoteker opdateres (VCm-kartoteker opdateres b}de i
VCens DC og TS).
VCen skal nu fjernes fra VC(AT)- eller VC(IT)-kartoteket i DC.
Herefter sendes besked til VCens TS om afmeldingen:
- Modtager: 02 17 22 00000 VCs TS
- Afsender: 02 00 00 00000 VCs DC
- Operationskode: "Afmeld VC"
- Datadel: 02 17 22 00014 VC
N}r afmeldingen er foretaget her, sendes kvittering til DC, der kvitterer til operat|ren:
Afmelding foretaget p} "VC-adresse".
>a3 Til-/afmelding af netknuder.
Det er muligt at til- og afmelde TSer, NCer og DCer. Disse operationer initieres
af operat|ren i DC gennem en MML-kommando p} operat|rkonsollen.
Eksempel:
TS-tilmelding: NC = "NC-adresse";
Ved tilmelding af en TS (TSn) under en bestemt NC (NCn) som angivet i MML-kommandoen,
v{lger utilitymodulet en passende netadresse for TSn. De f|rste to led i denne netadresse
skal v{re identisk med de tilsvarende led i NCns netadresse, det sidste led skal
v{re 0, mens tredje led v{lges, s} det er forskelligt fra tredje led i netadresserne p} de
|vrige TSer under samme NC og forskelligt fra 0. Herved bliver netadressen ogs} forskellig
fra alle andre netknuders adresse.
Herefter skal der oprettes en TSn-beskrivelse i den DC, hvorunder TSn tilsluttes (DCn).
Desuden foretages en {ndring i NCn-beskrivelsen i DCn. Denne {ndring best}r i at tilf|je TSn
i routningstabellen.
S} sendes meddelelse til NCn om oprettelsen med den nye netadresse:
- Modtager: NCn-adresse
- Afsender: DCn-adresse
- Operationskode: "Tilmeld TS"
- Datadel: TSn-adresse
I NCn tilkobles den fysiske forbindelse til TSn og den logiske forbindelse etableres bl.a.
ved {ndring i routningstabellen i NCn. Netadressen p} TSn sendes til TSn.
S} kvitteres til DC og operat|ren, at tilmeldingen er foretaget.
Tilmelding af en ny NC under en DC foreg}r p} lignende m}de. Operat|ren sender kommandoen:
Tilmeld NC;
hvilket resulterer i, at der bliver tilmeldt en NC under den DC, hvor kommandoen afgives.
Utilitymodulet i denne DC v{lger en passende netadresse for den nye NC. F|rste led i netadressen
skal v{re lig med f|rste led i DCs adresse, de sidste to led skal v{re 0, mens andet led
v{lges forskelligt fra 0 og forskelligt fra andet led i netadresserne for de |vrige
NCer under denne DC. DC forsynes med en NC-beskrivelse for denne NC, og NCen tilf|jes
i DCs routningstabel. Netadressen sendes ud til NCen og der kvitteres til operat|ren.
Tilmelding af en ny DC foreg}r fra en af de eksisterende DCer og kr{ver {ndringer i routningstabellerne
i de eksisterende DCer.
Afmelding af en netknude foreg}r ogs} gennem utilitymodulet. En afmelding initieres
fra den DC, hvor netknuden er tilmeldt og foruds{tter, at alle underliggende knuder
er afmeldt.
Eksempel MML-kommando til afmelding af TS:
Afmeld TS: "TS-adresse";
En s}dan kommando resulterer i fjernelse af TS-beskrivelsen i DC og {ndringer i DCs
NC-beskrivelse for den tilsluttede NC. Desuden {ndres routningstabellen i NC.
Afmelding af en NC foreg}r p} lignende m}de, mens afmelding af en DC kr{ver {ndringer
i de |vrige DCers routningstabeller.
>a3 Test af ATer internt og eksternt.
Test af en AT kan foretages af operat|ren i DC gennem en MML-kommando, eks.:
Test int: adresse = "AT-adr";
MML-kommandoen fortolkes af operat|rmodulet og afleveres til UTIL.
UTIL opretter en meddelelse:
- Modtager: "ATs TS"
- Afsender: "DC-adresse"
- Operationskode: "AT-test int"
- Datadel: "AT-adresse"
Meddelelsen sendes s}ledes til TS, der skal udf|re testen. N}r testen er udf|rt, sendes resultatet
heraf til DC, hvorefter det udskrives p} konsollen.
Ekstern test kan udf|res ved en analog kommando. Desuden kan ekstern test udf|res p} et enkelt
s{t data.
Eksempel:
Test ext: adresse = "AT-adr", data = 01010101;
Den resulterende meddelelse fra DC til ATs TS indeholder i datadelen b}de AT-adresse og det
valgte datas{t. Som svar p} denne test f}s datos{ttet som det ser ud, efter testen er
udf|rt.
>a2 Logmodul.
>a3 Logmodulets opgaver.
Logmodulet har f|lgende opgaver:
- Udskrivning af logmeddelelser til logfil.
- Printerudskrifter af udvalgte dele af logfilen.
- Dump af logfilen til magnetb}nd.
I de n{ste afsnit vil vi beskrive hvorledes disse opgaver udf|res.
>a3 Logmeddelelser.
Logmodulet vedligeholder logfilen. Logfilen er den fil, hvor alle logmeddelelser
skrives ud.
>a4 Logmeddelelsens indhold.
En logmeddelelse skives p} fil som
en
record indeholdende f|lgende information:
- Afsenderadresse
- Modtageradresse
- Tidspunkt for generering af logmeddelelsen
- Den oprindelige meddelelse (incl. operationskode)
Bem{rk, at afsender- og modtageradr. er de oprindelige adresser. Ved modtagelsen i DC
var disse adresser en del af pakkens dataindhold.
>a4 Logmeddelelsers oprindelse.
En logmeddelelse genereres af TSer, NCer eller DCer i nettet hver gang der indtr{ffer
"en begivenhed". Det sker f.eks. ved afsendelse af en alarm fra en TS, n}r alarmen er skrevet ud i VCens TS, o.s.v.
Endvidere genereres logmeddelelser i DCen selv, n}r:
- Operat|ren taster en kommando
- Utilitymodulet udf|rer en kommando
- Databasemodulet udf|rer en kommando
- Logmodulet udf|rer en kommando (bortset fra
logning af en meddelelse)
>a4 Logfilens udseende.
Logfilen indeholder logmeddelelser i form af records: en record pr. meddelelse.
Disse records er af variabel l{ngde (og indeholder alle deres l{ngde i f|rste ord).
Selve filen er opdelt i blokke a N segmenter.
F|rst p} hver blok st}r hvilket tidsrum denne blok rummer logmeddelelser fra.
>a3 Printerudskrifter fra logfilen.
P} anfordring (fra operat|rmodulet) skal logmodulet kunne udskrive n{rmere angivne logmeddelelser
i l{seligt format, b}de ud fra den del af logfilen, der befinder sig p} discen, og ud fra
magnetb}nd.
Operat|ren kan f.eks. bede om en liste over alle h{ndelser omkring en given AT i et givet tidsrum.
Eksempel:
Udskriv log: tid = 020280-040280,
adresse = 03 17 23 12345;
>a3 Dump af logfilen.
Med passende mellemrum skal logfilen dumpes til magnetb}nd.
Logmodulet giver operat|ren besked i god tid f|r logfilen er fuld:
Advarsel: dump logfilen
Operat|ren kan derefter initiere dump af logfilen ved at indtaste p} hovedkonsollen:
Dumplog;
>a2 Errorhandler.
Errorhandler indeholder programmel til behandling af fejlmeddelelser og skal desuden v{re
i stand til at reloade underliggende netknuder efter break-down.
Ved reload af underliggende netknuder hentes den n|dvendige information hertil fra databasen, hvorefter den sendes
til den p}g{ldende netknude i form af almindelige netpakker.
Fejlmeldinger til DC afleveres i errorhandler (EH), der s} s|rger for den n|dvendige behandling.
Fejl kan opdeles i f|lgende kategorier:
1) Fejl mellem AT og TS
2) Fejl mellem VC og TS
3) Fejl p} nettet
>a3 Fejl mellem en AT og TS.
Fejl mellem en AT og en TS opdages i DCs EH ved, at der kommer en liniealarm eller en
transmissionsalarm.
En liniealarm optr{der, n}r der har v{ret to transmissionsfejl i tr{k. Transmissionsalarmer
optr{der, n}r antallet af transmissionsfejl overstiger en bestemt gr{nse.
Ved AU-status sendes ikke alarm til DC, kun til prim{r VC.
EH reagerer p} en alarm ved at udskrive alarmen p} en sk{rm i DC, hvorved en del af behandlingen overlades til en operat|r.
Eksempel p} sk{rmudskrift:
Liniealarm: "AT12-adresse"
Ved transmissionsalarm sender EH ordre tilbage til ATs TS om at nulstille transmissionsfejlt{lleren.
>a3 Fejl mellem VC og TS.
Fejl mellem en VC og en TS opdages i DCs EH p} en af tre m}der, enten ved at der kommer en
liniealarm (p.g.a. to transmissionsfejl i tr{k), eller en transmissionsalarm (n}r gr{nsen for
antal transmissionsfejl er overskredet), eller hvis VC er af type AT, kan der komme statusalarm
(efter en STATUS-meddelelse fra AT til TS).
EH s|rger for udskrivning af disse alarmer p} en datask{rm i DC, hvor operat|ren s} skal s|rge for den
videre behandling af fejlen.
Eksempel:
Statusalarm: "VC8-adresse"
Desuden modtager EH de alarmer, som den p}g{ldende VC ikke selv er i stand til at modtage.
EH udskriver ogs} disse alarmer p} datask{rm.
Eksempel:
Alarm fra "AT78-adresse" til "VC8-adresse": 11
Operat|ren p} DC kan nu v{lge gennem en kommando til OPT enten at overf|re den p}g{ldende VCs
vagt til en anden VC, eller at VCs abonnenter ikke l{ngere skal POLLes.
I f|rste tilf{lde giver OPT utilitymodulet ordre til at udf|re en vagtoverf|rsel.
I andet tilf|lde giver OPT besked til EH om oph|r af POLL.
Ved standsning af POLL, skal EH sende en meddelelse herom til alle TSer
med abonnenter, der har denne VC som PVC. Meddelelsen kan have f|lgende format:
- Modtager: En af de p}g{ldende TSer
- Afsender: DCs adresse
- Operationskode: Poll oph|r
- Datadel: VC-adresse
Herefter s|rger TSerne selv for at oph|re med at polle de p}g{ldende ATer.
>a3 Fejl p} nettet.
Ved fejl p} nettet (TS, linien mellem TS og NC, NC eller linien mellem NC og DC) skal nederste
fungerende knude (d.v.s. NC eller DC) sende meddelelse herom til EH.
Eksempel p} meddelelse:
- Modtager: "DC-adresse"
- Afsender: "NC1-adresse"
- Operationskode: netfejl
- Datadel: "TS1-adresse"
EH udskriver fejlen p} hovedkonsollen i DC.
Eksempel:
Netfejl: "TS-adresse" - "NC-adresse"
TSerne under bruddet s|rger for at underrette de underliggende VCer om fejlen, og holder op
med at polle de ATer, hvis PVC ligger p} den anden side af bruddet. EH skal underrette
alle fungerende NCer, der s} underretter deres underliggende TSer om fejlen.
Eksempel:
- Modtager: "NC2-adresse"
- Afsender: "DC-adresse"
- Operationskode: Netfejl
- Datadel: "TS1-adresse"
og
- Modtager: "TS2-adresse"
- Afsender: "NC2-adresse"
- Operationskode: Netfejl
- Datadel: "TS1-adresse"
Operat|ren i DC kan v{lge mellem f|lgende muligheder:
1) EH modtager alarmer fra ATer uden for bruddet
til VCer under bruddet.
2) EH overf|rer involverede VCers vagt til VCer
uden for bruddet.
3) Poll af ATer, hvis PVC er involveret i bruddet,
standses.
Indtil operat|ren har meddelt andet, sendes alarmer fra ATer uden for bruddet med adresse p} VC
under bruddet til EH, der udskriver dem p} konsollen. Operat|ren kan omadressere disse alarmer.
Alarmer fra ATer under bruddet til PVCer uden for burddet kan ikke komme frem, hverken til PVC eller DC.
Vagten p} PVC kan heller ikke overf|res til en VC under bruddet, da kun
PVC og DC har myndighed til dette, og ingen af disse har forbindelse til den anden side af bruddet.
Det er alts} n|dvendigt at oph|re med at polle de ATer under bruddet, hvis PVC ligger over bruddet.
Det har den bivirkning, at alarmer til AVCer under bruddet heller ikke kan komme frem.
Eksempel:
>ne14
>sp14
TS1 oph|rer med at polle AT, da alarmer til PVC ikke kan komme igennem hverken til PVC eller DC.
Som bivirkning ses, at alarmer fra AT til AVC ikke kommer igennem, selv om forbindelsen her
er i orden.
Operat|ren kan via en kommando til OPT overf|re vagten p} VCer under bruddet til VCer uden for bruddet.
Denne vagtoverf|rsel vil p.g.a. bruddet kun blive gennemf|rt uden for bruddet og g{lder
s}ledes kun for de af VCernes abonnenter, der ligger uden for bruddet. Abonnenter under bruddet, som stadig har forbindelse
til VCerne her, ber|res ikke af vagtoverf|rslen.
Eksempel:
>ne14
>sp14
AT1 og AT2 har VC1 som PVC. Efter bruddet mellem NC1 og TS1, sender operat|ren ved DC
kommandoen:
Overf|r vagt: afsender = "VC1", modtager = "VC2";
til OPT, hvor den fortolkes og afleveres til UTIL.
UTIL s|rger for at overf|re vagten fra VC1 til VC2. Dette registreres i flyttekartoteket i TS2,
men ikke i TS1 p.g.a bruddet. Herefter vil alarmer fra AT1 til PVC blive sendt til VC1,
mens alarmer fra AT2 til PVC bliver sendt til VC2.
N}r fejlen er repareret, sendes meddelelse til DCs EH herom.
Eksempel:
- Modtager: "DC-adresse"
- Afsender: "NC1-adresse"
- Operationskode: Netfejl rettet
- Datadel: "TS1-adresse"
Meddelelsen udskrives p} konsollen, f.eks.
NC1 - TS1 repareret
Herefter skal flyttekartotekerne i TSerne g|res konsistente, idet vagtoverf|rsler der er
foretaget, mens der var brud kun g{lder enten uden for eller under bruddet.
Situationen under det tidligere brud skal nu g{lde overalt i nettet.
Derfor skal EH for hver eneste VC under det tidligere brud have besked (fra TSer under bruddet) om VCens status,
d.v.s. om den har overf|rt vagten og i bekr{ftende fald til hvem.
Eksempel:
- Modtager: "DC-adresse"
- Afsender: "TS1-adresse"
- Operationskode: opdatering
- Datadel: "VC-adresse" (*VC1 har overf|rt*)
"VC3-adresse" (*sin vagt til VC3*)
Herefter skal EH rundsende disse oplysninger til alle TSer (uden for det tidligere brud),
der s} skal opdatere deres flyttekartoteker i overensstemmelse hermed.
>a2 Databasemodul.
Databasemodulet indeholder programmel til kommunikation med databasen. Dette programmel er ikke
fastlagt endnu og bliver derfor f|rst beskrevet p} et senere tidspunkt.
Databasen skal bl.a. indeholde 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.
En TS-beskrivelse indeholder et VCa-VCm-kartotek over aktuelle vagtoverf|rsler, et AT-kartotek over
tilsluttede ATer, et VC(AT)- og et VC(IT)-kartotek over tilsluttede VCer.
En AT-beskrivelse indeholder et AT-adressekartotek med adresse, kode og blokl{ngde p} alle VCer,
der kan modtage alarmer herfra.
En VC-beskrivelse indeholder et abonnentkartotek og et AT-TS-kartotek. Desuden er der et
VCa- og et VCm-kartotek til angivelse af lovlige vagtoverf|rsler hhv. til og fra denne VC.
Hvis VC-beskrivelsen d{kker en VC af type AT findes der ogs} et VC-adressekartotek
med netadresse og adressekode p} alle ATer, der er tilsluttet denne VC.
herudover indeholder databasen programmel til reload af netknuderne.
>a2 Netinterface.
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 netadresse), operationskode og datadel.
Modulet udpakker meddelelser til RC8000 fra nettet. Det checkes, at modtageradressen er lig med
DCs netadresse. Desuden afl{ses operationskoden for at afg|re hvilket modul, der skal behandle meddelelsen.
>a2 \vrige moduler.
BASIS-modulet skal indeholde det n|dvendige basisprogrammel, der ligesom de |vrige viste moduler
best}r af standardprogrammer, der ikke vil blive beskrevet her.
>a1 MODULER I RC3502.
>a2 NETPROGRAMMEL
Netprogrammellet i RC3502 s|rger for modtagelse, afsendelse og videresendelse af pakker.
N}r der kommer en pakke fra nettet, afg|r en rutningsalgoritme ud fra pakkens netadresse,
om pakken skal afleveres til RC8000, om den skal videresendes til et af de |vrige distriktscentres
RC3502 via en X.75 gateway, eller om den skal sendes nedad i nettet, og i s} fald til hvilken NC.
Det er ogs} op til netprogrammellet at kunne foretage n|dvendige retransmissioner.
Netprogrammellet har desuden til opgave at overv}ge RC8000, de underliggende NCer og de |vrige DCers
RC3502. Ved fejl i en netknude sendes meddelelse herom til DC.
«eof»