|
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: 62976 (0xf600)
Types: TextFileVerbose
Names: »olddcsys3«
└─⟦a41ae585a⟧ Bits:30001842 SW-save af projekt 1000, Alarm-system
└─⟦72244f0ef⟧
└─⟦this⟧ »olddcsys3«
>fo @~SP.DCSYS.3/3~@
>a1 UTILITYMODUL
Utilitymodulet aktiveres enten gennem MML-kommandoer fra
operat|rkonsollen via operat|rmodulet, fra terminalen p}
ekspeditionskontoret eller fra netinterface.
Modulet udf|rer f|lgende funktioner:
Vagtflytning
Oprettelse og nedl{ggelse af abonnenter
Oprettelse og nedl{ggelse af vagtcentraler
Intern test af ATer
Start og stop poll af abonnenter
Start poll af vagtcentraler
Servicepoll
Taksering
Opdatering af servicegr{nse, stop poll gr{nse
og max. antal successive liniefejl
Behandling af krypteringsn|gler
Afsendelse af abonnentoplysninger
>a1 VAGTFLYTNING
Vagtflytning kan initieres enten af den vagtcentral (VCa), der
for tiden har ansvaret for de ATer, der skal flyttes, eller af
operat|ren p} det distriktscenter (DCa), hvorunder abonnentgruppens
VC er tilsluttet. DCa er det eneste distriktscenter, der har de
n|dvendige oplysninger (VCm-tabel).
N}r en vagtflytning initieres af en VC, styres vagtflytningen af
denne VCs TS, ellers er det DC selv, der styrer vagtflytningen.
>a2 Anmodning om vagtflytning
En vagtflytning foretaget af DCa starter s}ledes:
Operat|ren sender denne MML-kommando til OPT:
vagtflytning : afs = "VCa", modt = "VCm";
Kommandoen fortolkes af OPT og afleveres til utility-modulet
som meddelelsen "anmodning om vagtflytning":
modtageradresse : VCm-adresse
afsenderadresse : DCa-adresse
operationskode : 5.0
datadel : VCa-adresse
Utilitymodulet checker, at VCm er opf|rt i VCa's VCm(AT)- eller
VCm(IT)-tabel (afh{ngig af VCa's type). Hvis VCa er af type AT,
og VCm findes i VCm(AT)-tabellen, kr{ves desuden at denne indgang
indeholder et 1-tal i modtagerfeltet, s} VCm er lovlig modtager af
vagtflytning fra VCa.
Hvis dette ikke er opfyldt, returneres meddelelsen med operationskoden
15.4 til udskrivning af:
ulovlig modtager af vagtflytning
Hvis VCm godkendes, sendes 5.0-meddelelsen til VCm.
Senere modtages en kvittering fra VCm:
>ne 4
modtageradresse = DCa-adresse
afsenderadresse = VCm-adresse
operationskode = 5.1
datadel = VCa-adresse
0 = ikke accept, 1 = accept,
2 = afvist
En kopi af meddelelsen sendes til OPT til udskrivning af:
vagtflytning (ikke) accepteret/afvist af "VCm"
Hvis vagtflytningen ikke accepteres, standses her.
De tilsvarende meddelelser, der sendes ved en vagtflytning
initieret fra en VC, har ingen indvirkning p} DC, hvorfor
logmeddelelser herfor kun afleveres til logmodulet.
Accepteres vagtflytningen, forts{ttes automatisk med en simpel flytning
af VCa's egen abonnentgruppe og derefter en videreflytning for alle
abonnentgrupper, som VCa for tiden har ansvaret for.
>a2 Vagtflytning af egne abonnenter
Der sendes en meddelelse om vagtflytning:
modtageradresse = VCm-adresse
afsenderadresse = DCa-adresse
operationskode = 5.2
datadel = VCa-adresse
VCm-adresse
index i VCaVCm-tabel
Efter modtagelsen i VCm inds{tter VCm VCa-adressen i sin aktuel
VCe-tabel og kvitterer med:
modtageradresse = DCa-adresse
adsenderadresse = VCm-adresse
operationskode = 5.3
datadel = -
Denne {ndring skal ogs} foretages i VCm's aktuel VCe-tabel i DC.
Hvis DCa = VCm's DC, foretages denne {ndring ved afsendelse af
5.2-meddelelsen, ellers foretages den p} grundlag af logmeddelelsen
for 5.2-meddelelsen. (0.0 - 5.2 meddelelsen). Der skal ogs} foretages
{ndring i VCm's DC, n}r en s}dan meddelelse sendes i forbindelse
med vagtflytning initieret fra en VC. Denne {ndring foretages ogs}
p} grundlag af 0.0 - 5.2-meddelelsen. Hvis den DC, der modtager
logmeddelelsen er lig med VCa's DC, foretages {ndring af VCa's aktuel
VCm til VCm-adressen, og hvis DC = VCm's DC, foretages inds{ttelse
af VCa-adressen i VCm's aktuel VCe-tabel.
P} grundlag af 5.3-kvitteringen fra VCm opdateres VCa's "aktuel VCm"
p} DCa til at indeholde adressen p} VCm.
DCa fors|ger at opdatere VCa's egen aktuel VCm ved at sende en
5.2-meddelelse til VCa.
Herefter sendes meddelelse om vagtflytningen til alle TS'er i VCa's
AT-TS-tabel:
modtageradresse = TS-adresse
afsenderadresse = DCa-adresse
operationskode = 5.2
datadel = VCa-adresse
VCm-adresse
index i VCaVCm-tabel
Denne meddelelse vil resultere i en opdatering af disse TSers
VCaVCm-tabel. 5.2-meddelelser til TS indeholder i datadelen
index for VCa-indgangen i Tsens VCaVCm-tabel. DCa afl{ser dette
index i AT-TS-tabellen.
Samme opdatering skal naturligvis ogs} foretages i TS'ernes
DCer, ogs} n}r meddelelsen er afsendt fra VCa. P} grundlag
af en 0.0 - 5.2-meddelelse, hvor den oprindelige modtageradresse
er en TS-adresse, og logmeddelelsens modtageradresse er lig med
TSens DC, foretages opdatering af TSs VCaVCm-tabel.
TS kvitterer til DCa:
modtageradresse = DCa-adresse
afsenderadresse = TS-adresse
operationskode = 5.3
datadel = tom
DCa opsamler kvitteringer og eventuelle returneringer fra alle TSer.
>a2 Videreflytning
Der skal nu foretages en videreflytning af de abonnentgrupper,
som VCa for tiden har ansvaret for.
Derfor sendes en meddelelse om videreflytning til alle VCer i
VCa's aktuel VCe-tabel:
modtageradresse = VCe-adresse
afsenderadresse = DCa-adresse
operationskode = 5.10
datadel = VCa-adresse
VCm-adresse
P} grundlag af denne checkes, at VCe's aktuel VCm indeholder
VCa-adressen. Hvis dette er tilf{ldet, {ndres aktuel VCm
til at indeholde VCm-adressen.
Samme {ndring skal ske i databasen i VCe's DC. Hvis VCe's
DC = DCa foretages den ved afsendelsen af 5.10-meddelelsen,
ellers p} grundlag af logmeddelelsen herfor. Ved vagtflytning
initieret af VCa foretages samme {ndring efter 0.0 - 5.10-meddelelsen,
ogs} i de tilf{lde hvor VCe's DC = VCa's DC.
Hvis VCe's aktuel VCm ikke indeholdt VCa-adressen, er der opst}et
en fejlsituation og VCe kan afsl} videreflytningen. I det tilf{lde
skal DC tage aktion. Evt. unders|ges om fejlen ligger i VCa's
aktuel VCe-tabel, eller om den ligger i VCe's aktuel VCm.
Hvis VCe accepterer videreflytningen, udf|rer den nu en
flytning af egne abonnenter til VCm. Her er der ikke behov for nogen
videreflytning,
da VCe i forbindelse med sin tidligere flytning til VCa udf|rte
videreflytning for alle de abonnentgrupper, den p} det tidspunkt
havde ansvaret for. VCe kan ikke siden have f}et ansvaret for nogen
abonnentgruppe, da dens vagt har v{ret overf|rt.
Hver VCe kvitterer:
modtageradresse = DCa-adresse
afsenderadresse = VCe-adresse
operationskode = 5.11
datadel = VCa-adresse
VCm-adresse
0 = ikke accept, 1 = accept
>a1 RETURNERING.
Returnering af vagt til en vagtcentral kan initieres enten af
vagtcentralen selv eller af dennes DC.
Initiering fra VCs DC foreg}r enten automatisk efter genoprettelse af
alarmnettet eller ved at operat|ren indtaster:
vagtreturnering: "VCa";
hvilket af OPT overs{ttes til en ordre om at foretage vagtreturnering:
modtageradresse = VCa-adresse
afsenderadresse = VCa's DC-adresse
operationskode = 5.8
datadel = -
Meddelelsen afleveres til UTIL, der finder frem til VCa's aktuel VCm
og aktuel VCe-tabel og inds{tter dette i datadelen. Herefter sendes meddelelsen af sted.
I VC gemmes den tilsendte v{rdi af aktuel VCm og aktuel VCe-tabel.
De tilsendte data
er ikke n|dvendigvis identiske med indholdet af aktuel VCm og aktuel
VCe-tabel i VCs TS. En s}dan
inkonsistens kan opst} i forbindelse med alarmnetudfald, idet det er
muligt for DC at overf|re vagten for abonnenter over bruddet til een
VCm og for VC at overf|re vagten for abonnenter under bruddet til en
anden VCm eller returnere vagten for disse.
Fra VC-connector svares med en kvittering til DC:
modtageradresse = VCa's DC-adresse
afsenderadresse = VCa-adresse
operationskode = 5.9
datadel = aktuel VCm-adresse
aktuel VCe-tabel
Datadelen heri indeholder v{rdien af VCs aktuel VCm og aktuel VCe-tabel
i TS. UTIL f}r meddelelsen og opdaterer aktuel VCm og aktuel VCe-tabel
i overensstemmelse med de tilsendte data. Aktuel VCe-tabel i DC skal
indeholde den fra TS tilsendte tabel, dog gemmes DCs version af
VCe-tabellen.
TS foretager den beordrede returnering fra den aktuel VCm, der blev
tilsendt fra DC. Hvis TSs v{rdi af denne var forskellig fra 0, skal
returneringen omg}ende efterf|lges af en vagtflytning til TSs
aktuel VCm.
Under returneringen m} TSs aktuel VCm ikke s{ttes til 0 (hvilket normalt
sker ved en returnering), da VCa givetvis ikke er bemandet. En fastholdelse
af v{rdien resulterer i, at alarmer til VCa vil blive omadresseret til
aktuel VCm.
Vagtreturnering kan s}ledes ikke styres fra DC, men en del meddelelser, der
sendes under en returnering, resulterer i tabel{ndringer. Disse tabel{ndringer
skal naturligvis afspejles i DC, hvilket beskrives her.
Returneringen starter med en 5.4-anmodning fra VCa til VCm, hvilket
ikke ber|rer DC. Datadelen i denne anmodning indeholder VCa-adressen
og den fra DC tilsendte aktuel VCe-tabel.
Herefter sendes en kvittering for anmodning om returnering:
>ne 6
modtageradresse = VCa-adresse
afsenderadresse = VCm-adresse
operationskode = 5.5
datadel = 0= ikke accept, 1= accept
antal VCe-adresser
VCe-adresser
Hvis datadelen indeholder et 1-tal for accept, er der ved afsendelse af
denne meddelelse sket en {ndring hos afsenderen, d.v.s. VCm. De VCe-adresser,
der findes i 5.5-datadelen, er de adresser, der fandtes i b}de VCa's
aktuel VCe-tabel
fra DC
og VCm's
aktuel VCe-tabel, og angiver s}ledes de vagtcentraler, hvis vagt skal
returneres til VCa. Disse adresser og VCa-adressen er nu blevet
fjernet fra VCm's aktuel VCe-tabel.
En logmeddelelse 0.0-5.5 til en DC, der er identisk med VCm's DC, skal
derfor resultere i samme {ndring p} DC.
Ved modtagelsen af 5.5-meddelelsen skal der foretages {ndringer i
VCa's TS: De VCer, hvis vagt nu bliver returneret til VCa (og
derefter evt. videref|rt) er de vagtcentraler, som DC har overf|rt
minus de, der har returneret siden hen. VCa's egen aktuel VCe-tabel
kan indeholde andre vagtcentraler, hvis der er foretaget vagtflytning,
efter alarmnetudfaldet er opst}et. Opdateringen af VCa's egen aktuel
VCe-tabel skal foreg} ved, at elementerne tilsendt fra DCs version af
VCa's aktuel VCe-tabel fjernes fra VCa's egen aktuel VCe-tabel.
Herefter inds{ttes de vagtcentraler, hvis vagt nu bliver returneret
til VCa, dvs. de VCer der er angivet i 5.5-kvitteringen fra VCm.
P} denne m}de fjernes de vagtcentraler, der selv har foretaget
returnering, fra VCa's aktuel VCe-tabel i TS.
En logmeddelelse 0.0 - 5.5 til en DC, der er identisk med VCa's
DC skal resultere i samme {ndringer i VCa's aktuel VCe-tabel p}
DC. Her benyttes den "gemte" DC-version af aktuel VCe-tabel.
VCa's TS foretager en "AT-returnering" for hver indgang i VCa's AT-TS-tabel.
Herunder sendes meddelelse om vagtreturnering
til alle TSer, hvor vagtcentralen har abonnenter:
>ne 6
modtageradresse = TS-adresse
afsenderadresse = VC-adresse
operationskode = 5.6
datadel = VCa-adresse
VCm-adresse
index i VCaVCm-tabel
Denne meddelelse resulterer i en nulstilling af VCm-feltet i den indgang
i VCaVCm-tabellen, som indexet udpeger.
en 0.0-5.6-meddelelse, hvor modtager-DC er lig med TSs DC,
resulterer i samme {ndring.
VCa's TS foretager desuden returnering i form af videreflytning fra
VCm til VCa for alle VCe'er i 5.5-datadelen (se afsnit 2.3), hvorefter
returneringen er afsluttet.
Hvis aktuel VCm i TS var forskellig fra 0, forts{ttes med en
vagtflytning som beskrevet i kapitel 2. Vagtflytningen beh|ver dog
kun at omfatte de VCer, der netop er foretaget returnering for, dvs.
dvs. VCa og de VCer, der var angivet i datadelen af 5.5-meddelelsen
fra VCm til VCa.
>a1 OPRETTELSE AF AT.
DCs opgaver i forbindelse med oprettelse af en abonnent initieres
p} ekspeditionskontoret p} den DC, hvorunder abonnenten skal
tilsluttes.
>a2 Anmodning om oprettelse.
Grundlaget for en oprettelse er en anmodning herom fra den nye
abonnents prim{re vagtcentral. Denne anmodning indeholder de n|dvendige
oplysninger om den nye abonnent:
navn,
adresse,
om AT har parallelmodul
For PVC og hver AVC angives:
alarmnetadresse,
kode for VC,
blokl{ngde,
type (AT eller IT),
kode for AT,en, hvis VC er af type AT
om VC m} styre AT
Hvis der |nskes kryptering, afleveres en krypteringsordre til
operat|ren p} DC. Fremgangsm}den er beskrevet i afsnittet:
Krypteringsn|gler.
>a2 Administrativ oprettelse.
F|rst foretages en administrativ oprettelse p} DC.
P} ekspeditionskontoret genereres ud fra anmodningen (specielt
abonnentens adresse) en alarmnetadresse for den nye AT og LAM- og
PORT-nummer, hvor ATen skal tilsluttes TS.
Der fremkaldes et sk{rmbillede indeholdende de kommandoer, der
kan v{lges imellem. Cursoren placeres ved kommandoen
oprettelse af AT
hvorefter en aktivering af SEND-tasten vil fremkalde et sk{rmbillede
til oprettelse af en abonnent.
Dette sk{rmbillede indeholder felter til angivelse af abonnentens
navn og adresse, alarmnetadresse for ATen, fysisk tilkobling
(LAM- og PORT-nummer), beskrivelse af PVC og AVCer, og om der
benyttes parallelmodul.
>ex Sk{rmbillede til oprettelse
>ne 14
navn: Peter Jensen
adresse: \stergade 40
alarmnetadresse: 21723 2345
tilkobling: 8 - 4
parallelmodul: +
alarmnetadr VC-kode type bloklgd AT-kode styring
VC(IT) VC(AT)
PVC 21722 0014 1 IT 1 +
AVC 10416 0018 2 IT 2 -
AVC 10416 0028 3 AT 72 -
Blokl{ngde betyder antal bytes i een alarm og angives kun for
vagtcentraler af type IT, da vagtcentraler af type AT altid benytter
en blokl{ngde p} 1.
VC-kode angiver det nummer, hvorunder den nye AT kender en VC. AT-kode
angiver det nummer, hvorunder en VC af type AT kender denne AT.
Sk{rmbilledet afleveres til utilitymodulet.
Her udledes adressen p} den TS, hvor ATen tilsluttes ud fra
ATs alarmnetadresse. Oplysningerne inds{ttes som en ny indgang i denne
TSs AT-tabel. I felterne poll, akkumuleret pakket{ller og sidste
pakket{ller inds{ttes v{rdien 0.
Hvis den angivne fysiske tilkobling ikke er ledig,
v{lger UTIL en ledig indgang og udskriver dette p}
ekspeditionsterminalen. DC f|rer regnskab med de tilkoblingsmuligheder,
der er til r}dighed for hver TS, og hvilke af disse der er i brug.
Desuden oprettes en VC-adressetabel, der ogs} inds{ttes i databasen.
Denne skal i hver indgang indeholde kode, VC-index ,
blokl{ngde og angivelse af, om VCm m} styre denne AT.
VC-index findes ud fra TSens VCaVCm-tabel i DC. Det udg|r nummeret
p} den indgang, der indeholder VC-adressen i VCa-feltet. Hvis en
s}dan indgang ikke eksisterer, benyttes den n{ste frie indgang.
VC-adressen inds{ttes s} i VCa-feltet og VCm-feltet s{ttes til 0.
Data om PVC placeres i f|rste indgang i VC-adresse-tabellen.
Utilitymodulet udskriver s} en ordrebekr{ftelse til PVC og en ordreseddel
til installationskontoret
med angivelse af abonnentens navn og adresse, TS-adressen, den
fysiske tilkobling, og om der er parallelmodul.
>a2 Logisk oprettelse.
Herefter sender UTIL de n|dvendige oplysninger som angivet i
nedenst}ende meddelelse til den TS, som den nye AT tilsluttes.
Meddelelse om oprettelse af AT:
modtageradresse = ATs TS-adresse
afsenderadresse = ATs DC-adresse
operationskode = 6.0
datadel = AT-mikroadresse
LAM-nummer
Port-nummer
VCaVCm-index for PVC
Efter behandling af denne meddelelse kvitteres med:
>ne 7
modtageradresse = ATs DC-adresse
afsenderadresse = ATs TS-adresse
operationskode = 6.1
datadel = AT-mikroadresse
LAM-nummer
PORT-nummer
VCaVCm-index
Desuden sendes for PVC og siden for hver AVC en meddelelse til ATs TS om
opdatering af VC-adressetabel, hvorved der bliver indsat en indgang for
hver af disse vagtcentraler i ATens VC-adressetabel i TS:
modtageradresse = ATs TS-adresse
afsenderadresse = ATs DC-adresse
operationskode = 10.0
datadel = VC-adressetabel-indgang
En VC-adressetabel-indgang best}r af adressekode, index til VCaVCm-tabel
blokl{ngde og angivelse af, om VCen m} styre. Hver af disse meddelelser
kvitteres efter opdatering i TS med en meddelelse med operationskode 10.1.
Herefter skal de angivne VCer og deres DCer have besked om oprettelsen
til brug ved opdatering af deres AT-TS-tabel, AT-adressetabel,
PVC- og AVC-tabel.
Opdateringen i AT-TS-tabellen i VCs TS afh{nger af oplysningerne
i AT-TS-tabellen p} DC. Felterne i AT-TS-tabellen i VCs DC er ikke
identiske med felterne i AT-TS-tabellen i VCs TS. I VCs AT-TS-tabel
i TS skal feltet TS-type opdateres ud fra felterne antal AT(PVC)
og antal AT(AVC) i AT-TS-tabellen p} VCs DC.
>ne 16
>sp 14
>fg AT-TS-tabel i DC
>ne 16
>sp 14
>fg AT-TS-tabel i TS
Derfor sendes disse meddelelser f|rst til VCernes DC og herefter
til VCernes TS.
Hvis VCs DC er forskellig fra ATs DC, sendes f|lgende meddelelse
om opdatering af AT-TS-tabel og AVC-tabel eller PVC-tabel og AT-adresse-tabel
til VCs DC:
>ne 12
modtageradresse = VCs DC-adresse
afsenderadresse = ATs DC-adresse
operationskode = 10.4
datadel = 1 (= tilmelding)
AT-adresse
VC-adresse
0= AVC, 1= PVC
Hvis 0 = AVC, s} PVC-adresse
ellers antal AVCer og adresser
0= ikke PAM, 1= PAM
index for VC i ATs TSs VCaVCm-
tabel
AT-kode ved VC(AT)
Denne meddelelse afleveres til UTIL-modulet. Herefter f|lger
en opdatering af databasen i VCs DC og en generering af
meddelelser til VC.
Hvis VCs DC er identisk med ATs DC, skal der foretages samme
opdatering i databasen og samme meddelelse til VC skal genereres,
men ovenst}ende meddelelse udelades.
Opdatering af databasen i VCs DC omfatter 3 ting:
1. Der oprettes en indgang i VCs AT-adressetabel
indeholdende AT-adresse, AVC/PVC, parallelmodul,
og ved VC(AT) adressekode.
2. I VCs AT-TS-tabel foretages f|lgende opdatering:
Hvis ATs TS indg}r i tabellen, t{lles 1 op i
antal AT (PVC) eller antal AT (AVC).
Hvis ATs TS ikke indg}r i tabellen, oprettes en
indgang for denne. Det medsendte index for VC i
ATs TSs VCaVCm-tabel inds{ttes. Antal AT (PVC)
og antal AT (AVC) s{ttes til 0 og 1 eller omvendt.
3. Hvis denne VC er PVC, skal der t{lles 1 op i AVC-
tabellen for hver AVC-adresse. De AVC-adresser,
der ikke indg}r i denne AVC-tabel i forvejen, ind-
s{ttes, og antal-feltet s{ttes til 1.
Hvis denne VC er AVC, skal der t{lles 1 op i PVC-
tabellen ved PVC-adressen. Hvis PVC ikke indg}r i
forvejen heri, inds{ttes PVC-adressen, og antal
s{ttes til 1.
S} oprettes en meddelelse til VC:
modtageradresse = VC-adresse
afsenderadresse = VCs DC-adresse
operationskode = 10.4
datadel = 1 (= tilmelding)
AT-TS-tabelindgang
Tabelindgangen best}r af TS-adresse, TS-type (0/1) og index i VCaVCm-tabellen
i ATs TS. Meddelelsen sendes til VC, hvor den giver anledning til {ndring
af AT-TS-tabellen.
Hvis VC er af type AT sendes desuden en meddelelse:
modtageradresse = VC-adresse
afsenderadresse = VCa DC-adresse
operationskode = 10.2
datadel = inds{ttelse
AT-adresse
AT-kode
der giver anledning til inds{ttelse af en ny indgang for denne AT
i AT-adressetabellen med AT-adresse og AT-kode. Meddelelsen sendes
ogs} til de VC(AT)er, som denne VC har vagtflytteordning med, da deres
AT-adressetabeller skal v{re identiske.
Disse 10.2-meddelelser kvitteres med 10.3-kvitteringer til VCs DC.
Herefter sendes kvittering til VCs DC:
modtageradresse = VCs DC-adresse
afsenderadresse = VC-adresse
operationskode = 10.5
datadel = 1 = tilmelding
AT-TS-tabelindgang
N}r VCs DC har modtaget kvittering for de(n) udsendte meddelelse(r),
kvitteres med en 10.5-meddelelse til ATs DC.
Meddelelsen afleveres til UTIL, der opsamler 10.5 kvitteringer
og desuden 6.1-kvitteringen fra ATs TS.
N}r alle kvitteringer er indkommet, afleveres en af kvitteringerne
(10.5 eller 6.1) til OPT, hvor den resulterer i udskriften:
AT oprettet: "AT-adresse"
>a2 Test af transmission.
Efter fysisk oprettelse af AT og AU, indgives en klarmelding
fra mesterkontoret til operat|ren p} ATs DC. Operat|ren har herefter
til opgave at afteste ATen ved en intern test og check af AT-VC-forbindelse
(beskrevet i et senere kapitel).
>a2 Start af poll.
N}r ATen fungerer korrekt, sender operat|ren en "DC-tilladelse til start
poll" til PVC:
>ne 4
modtageradresse = PVC-adresse
afsenderadresse = ATs DC-adresse
operationskode = 6.4
datadel = AT-adresse
PVC sender en "PVC-tilladelse" til start poll:
>ne 4
modtageradresse = ATs DC-adresse
afsenderadresse = PVC-adresse
operationskode = 6.5
datadel = AT-adresse
n}r PVCs del af installationen er udf|rt.
Meddelelsen afleveres til UTIL.
UTIL afleverer en kopi til OPT, der udskriver:
poll startes : AT-adresse
N}r begge meddelelser er afsendt, forts{tter UTIL automatisk
med ordre om poll:
>ne 4
modtageradresse = AT-adresse
afsenderadresse = ATs DC-adresse
operationskode = 9.0
datadel = 1 (= start)
initialv{rdi for transmissions-
fejlt{ller
poll interval
AT kvitterer:
>ne 4
modtageradresse = ATs DC-adresse
afsenderadresse = AT-adresse
operationskode = 9.1
datadel = 1 (= start)
initialv{rdi for transmissions-
fejlt{ller
poll interval
Denne kvittering afleveres til OPT, der udskrives:
poll startet: "AT"
>a1 OPRETTELSE AF VC.
Oprettelse af en VC startes fra ekspeditionskontoret p}
den DC, hvorunder vagtcentralen skal tilsluttes.
>a2 Anmodning om oprettelse.
Grundlaget for en oprettelse er en anmodning fra den nye
vagtcentral. Denne anmodning indeholder de n|dvendige
oplysninger om den nye VC:
>ne 5
navn,
adresse,
type (IT eller AT)
hvis type AT, om VC har parallelmodul
VCer, der |nskes overf|rt vagt til eller fra
Hvis der |nskes kryptering afleveres en krypteringsordre
til operat|ren p} DC.
>a2 Administrativ oprettelse.
F|rst foretages en administrativ oprettelse p} DC.
P} ekspeditionskontoret genereres ud fra anmodningen en alarmnetadresse
for den nye VC og desuden LAM- og PORT-nummer, hvor VCen tilsluttes TS.
Hvis vagtcentralen skal kunne kommunikere med VC(AT)er, bestemmes en
adressekode, hvormed disse VC(AT)er kan identificere den nye VC.
Der fremkaldes et sk{rmbillede indeholdende de kommandoer,
der kan v{lges imellem. Cursoren placeres ved kommandoen
oprettelse af VC
hvorefter en aktivering af SEND-tasten vil fremkalde et
sk{rmbillede til oprettelse af en vagtcentral.
Dette sk{rmbillede indeholder felter til angivelse af
abonnentens navn og adresse, alarmnetadresse for VCen, type,
fysisk tilkobling, adressekode, om der benyttes parallelmodul,
VCer der |nskes vagtflytteordning med.
>ex Sk{rmbillede til oprettelse af VC
>ne 20
navn: Alarmetta
adresse: N|rreport 38
alarmnetadresse: 21722 0014
type: IT
tilkobling: 3 - 5
adressekode: 7
parallelmodul:
vagtflytteordning:
alarmnetadresse a/m type
21722 0013 m IT
10416 0018 a AT
21722 0028 a AT
Sk{rmbilledet afleveres til utilitymodulet, der udleder adressen
p} den TS, hvor VCen tilsluttes.
Hvis den angivne alarmnetadresse eller fysiske tilkobling ikke er
ledig, v{lger UTIL selv en ledig alarmnetadresse eller tilkobling.
Denne udskrives p} ekspeditionsterminalen.
Oplysningerne bortset fra data om vagtflytning inds{ttes som en
indgang i denne TSs VC(AT) eller VC(IT)-tabel p} DC, afh{ngigt af den
nye VCs type. V{rdien i felterne poll, aktuel VCm, akkumuleret
pakket{ller, sidste pakket{ller og krypteringsn|gle s{ttes til 0.
Desuden oprettes f|lgende tabeller, som er tomme indtil videre:
>ne 7
AT-adressetabel
AT-TS-tabel
VCa-tabel
VCm(AT)- eller VCm(IT)-tabel
aktuel VCe-tabel
PVC-tabel
AVC-tabel
Herefter skal de angivne VCaer ("a" i sk{rmbilledet) og VCmer
("m" i sk{rmbilledet) inds{ttes i VCa-tabellen og VCm(AT)- eller
VCm(IT)-tabellen.
F|rst checkes de indtastede data. Hvis VC selv er af type AT,
skal alle VCaer ogs} v{re af type AT.
For hver VCm foretages f|lgende:
F|rst sendes en anmodning om opdatering af VCa-tabel:
>ne 7
Modtageradresse = VCm-adresse
Afsenderadresse = VCs DC-adresse
Operationskode = 9.6
Datadel = 1 = inds{ttelse
VC-adresse
hvis VCm er af type AT:
VC-kode
Hvis VCm accepterer, skal VC inds{ttes i VCm's VCa-tabel i DC.
Hvis VCm desuden er af type AT, inds{ttes desuden VC-koden (dvs.
adressekode for VC), VC-adressen
og et 0 i VCm(AT)-tabellen i TS og DC, s} der herved etableres mulighed
for kommunikation. Herefter kvitteres til VCs DC.
Hvis VCm ikke accepterer, foretages disse {ndringer ikke, og der
sendes kvittering indeholdende et afslag.
Kvittering for anmodning om opdatering af VCa-tabel:
>ne 8
modtageradresse = VCs DC-adresse
afsenderadresse = VCm-adresse
operationskode = 9.7
datadel = 1 = inds{ttelse
VC-adresse
hvis VCm er af type AT:
VC-kode
0 = ikke accept, 1 = accept
hvis VC er af type AT og accept:
VCm-kode
Hvis VCm accepterer, foretages evt. {ndringer i VCm's TS
ved afsendelse af 9.7-meddelelsen. De kr{vede {ndringer i
VCm's DC foretages ved modtagelse af logmeddelelsen 0.0 - 9.7
hvis VCm's DC <> VCs DC. Hvis VCm's DC = VCs DC foretages
disse {ndringer ved modtagelsen af 9.7-kvitteringen.
Herudover skal der ske f|lgende ved modtagelse af 9.7-kvittering
med accept:
VCm inds{ttes i VCs VCm(AT)-eller VCm(IT)-tabel, afh{ngig af
VCs type. Hvis VC er af type AT, inds{ttes
desuden den medsendte adressekode for VCm (VCm-kode)
i feltet VC-kode og et 1-tal i modtager-feltet.
For hver VCa foretages f|lgende:
F|rst sendes en anmodning om opdatering af VCm(AT)- eller
VCm(IT)-tabel:
>ne 7
modtageradresse = VCa-adresse
afsenderadresse = VCs DC-adresse
operationskode = 9.4
datadel = 1 = inds{ttelse
VC-adresse
hvis VCa er af type AT:
VC-kode
Hvis VCa accepterer, skal VC-adressen inds{ttes i VCa's
VCm(AT)- eller VCm(IT)-tabel b}de i VCa's TS og DC. Hvis
VCa er af type AT, inds{ttes desuden VC-koden og et 1-tal
i VCm(AT)-tabellen. Samtidigt sendes accept til VCs DC.
Hvis VCa ikke accepterer, foretages ingen {ndringer, og der
sendes kvittering til VCs DC indeholdende et afslag.
>ne 8
modtageradresse = VCs DC-adresse
afsenderadresse = VCa-adresse
operationskode = 9.5
datadel = 1 = inds{ttelse
VC-adresse
hvis VCa er af type AT:
VC-kode
0 = ikke accept, 1 = accept
hvis VC er af type AT og accept:
VCa-kode og VCa's AT-adressetabel
Ved accept skal tilsvarende {ndringer foretages i databasen p}
VCa's DC. Hvis VCa's DC <> VCs DC, foretages disse {ndringer
p} grundlag af logmeddelelsen 0.0 - 9.5, ellers foretages de
ved modtagelsen af 9.5-meddelelsen.
Ved accept skal der desuden ske f|lgende efter modtagelsen
af 9.5-kvitteringen:
VCa inds{ttes i VCs VCa-tabel.
Hvis VC er af type AT, inds{ttes
VCa-koden , VCa-adressen og et 0 desuden
i VCs VCm(AT)-tabel til muligg|relse af kommunikation mellem
VC og VCa.
Indholdet af VCa's AT-adressetabel skal inds{ttes i VCs AT-adressetabel,
for at VC skal kunne kommunikere med VCa's ATer, n}r
VCa's vagt er overf|rt til VC.
>a2 Logisk oprettelse.
Herefter forts{tter UTIL med den logiske oprettelse ved at sende
de n|dvendige oplysninger til den TS, som den nye VC tilsluttes.
Meddelelse om oprettelse af VC:
>ne 10
modtageradresse = VCs TS-adresse
afsenderadresse = VCs DC-adresse
operationskode = 7.0
datadel = VC-mikroadresse
VC-type
LAM-nummer
PORT-nummer
Efter oprettelsen er foretaget her, kvitteres:
>ne 4
modtageradresse = VCs DC-adresse
afsenderadresse = VCs TS-adresse
operationskode = 7.1
datadel = VC-mikroadresse
VC-type
LAM-nummer
PORT-nummer
Desuden sendes opdateringsmeddelelser til inds{ttelse af indgange i
VCm(AT)- eller VCm(IT)-tabellen i den nye VC's TS. For hver indgang,
der er oprettet i DC's VCm(AT)- eller VCm(IT)-tabel sendes en meddelelse:
modtageradresse = VC-adresse
afsenderadresse = DC-adresse
operationskode = 10.6
datadel = inds{ttelse
VCm-tabel-indgang
En VCm(IT)-tabel-indgang indeholder kun alarmnetadressen p} den
modtagende vagtcentral, mens en VCm(AT)-tabel-indgang ogs} indeholder
en adressekode og desuden en kode, der angiver om vagtcentralen (VCm)
kan modtage vagt (kode = 1) eller ej (kode = 0).
Efter opdatering kvitteres for meddelelsen:
modtageradresse = DC-adresse
afsenderadresse = VC-adresse
operationskode = 10.7
datadel = inds{ttelse
VCm-tabel-indgang
Hvis vagtcentralen er af type AT udsendes meddelelser til inds{ttelse
af indgangene i AT-adressetabellen. For hver indgang sendes en
10.2-meddelelse, der kvitteres med en 10.3-meddelelse.
N}r alle kvitteringer (7.1, 10.7 og evt. 10.3) er modtaget p} DC,
udskrives
VC oprettet: "VC"
I tilslutning til den logiske oprettelse udskrives en ordrebekr{ftelse til vagtcentralen og
en ordreseddel til installationskontoret med angivelse af vagtcentralens
navn, adresse, TS-adresse, type fysisk tilkobling, adressekode og ved
type AT, om der er parallelmodul.
>a2 Test af transmission.
Efter f{rdigmelding af den fysiske oprettelse fra installationskontoret
foretages en aftestning af VC fra operat|rkonsollen. Hvis VC er
af type AT, kan dette g|res med en intern test.
>a2 Start poll.
N}r aftestningen er forl|bet tilfresstillende, startes pollning af
vagtcentralen. Denne procedure er beskrevet i et senere kapitel.
Vagtcentralen er nu klar til at f} oprettet abonnenter.
>a1 NEDL[GGELSE AF AT.
Nedl{ggelse af en abonnent foretages efter bestilling fra prim{r
vagtcentral ved operat|rkonsollen p} ATs DC. Under nedl{ggelsen indhenter
systemet accept fra ATs prim{r vagtcentral. Proceduren foruds{tter,
at poll af ATen er stoppet.
Proceduren aktiveres ved indtastning p} konsollen af:
Nedl{g AT: "AT-adresse";
Kommandoen fortolkes af OPT og afleveres til UTIL som meddelelsestypen
"anmodning om nedl{ggelse af AT":
Modtageradresse = -
Afsenderadresse = AT's DC-adresse
Operationskode = 6.6
Datadel = AT-adresse
Hvis AT-adressen h|rer ind under en anden DC eller ikke findes i
AT-tabellen, fremkommer f|lgende fejludskrift p} konsollen:
Ulovlig adresse
Dette sker ved at {ndre operationskoden til 15.10 og aflevere
meddelelsen til OPT. Hovedgruppe 15 anvendes til fejlbehandling
internt i DC.
Herefter checkes, at poll af den p}g{ldende AT er stoppet. Hvis ikke
sendes fejludskrift (15.12) til operat|ren, og proceduren standses.
>a2 Anmodning om nedl{ggelse
Hvis nedl{ggelsen accepteres, skal alarmnetadressen p} AT's PVC inds{ttes
som modtageradresse. Adressen findes i AT's VC-adressetabel, hvorefter
meddelelsen afleveres til netinterface.
Der afventes kvittering fra PVC:
Modtageradresse = AT's DC-adresse
Afsenderadresse = PVC-adresse
Operationskode = 6.7
Datadel = AT-adresse
0/1
1 i datadelen angiver accept p} anmodning, 0 angiver afslag. Kvitteringen
afleveres til UTIL, der s|rger for udskrivning p} konsollen gennem OPT:
Nedl{ggelse af "AT" accepteret/afsl}et
>a2 Nedl{ggelse af ATen selv
Hvis der er givet tilladelse til nedl{ggelsen, sendes nu en ordre om
nedl{ggelse til AT's TS og meddelelser herom til de VCer, som AT kan
sende alarmer til.
Ordre om nedl{ggelse til AT's TS:
Modtageradresse = AT's TS-adresse
Afsenderadresse = DC-adresse
Operationskode = 6.8
Datadel = AT-mikroadresse
Denne meddelelse vil resultere i tabel{ndringer i AT's TS, som ogs} skal
foretages i DC nu. [ndringerne p} DC best}r i at fjerne AT's indgang i TSens
AT-tabel og fjerne AT's VC-adressetabel.
Inden VC-adressetabellen fjernes fra databasen i DC
skal den dog l{ses og opbevares til brug ved afsendelse af meddelelser til
AT's VCer.
N}r nedl{ggelsen er foretaget i AT's TS, sendes en kvittering tilbage
til DC:
Modtageradresse = DC-adresse
Afsenderadresse = AT's TS-adresse
Operationskode = 6.9
Datadel = AT-mikroadresse
Denne kvittering afleveres til UTIL (der opsamler kvitteringer fra
AT's TS og AT's VCer).
>a2 Afmelding hos vagtcentralerne
Herudover skal hver VC i VC-adressetabellen have besked om afmeldingen
til brug ved opdatering af dens AT-TS-tabel og, hvis VC er af type AT
skal AT-adressetabellen opdateres b}de hos vagtcentralen selv og de
VC(AT)er, denne kan overf|re vagt til.
Selve opdateringen i AT-TS-tabellen afh{nger af oplysningerne i databasen
p} VC's DC. Felterne i AT-TS-tabellen i VC's DC er ikke identiske med
felterne i AT-TS-tabellen i VC's TS.
I VC's AT-TS-tabel i TS skal feltet TS-type opdateres ud fra felterne
antal AT (PVC) og antal AT (AVC) i AT-TS-tabellen p} DC (VC's DC).
Hvis VCs DC er forskellig fra AT's DC sendes derfor f|rst en meddelelse
til VCs DC:
>ne 9
Modtageradresse = VCs DC-adresse
Afsenderadresse = ATs DC-adresse
Operationskode = 10.4
Datadel = 0 (= afmelding,1= tilmelding)
ATs TS-adresse
VC-adresse
0/1 (AVC/PVC)
hvis 0 for AVC s} PVC-adresse
ellers alle AVC-adresser
Denne meddelelse afleveres til UTIL-modulet.
Herefter f|lger en opdatering i databasen i VCs DC og generering af
meddelelser til VC.
Hvis VCs DC er identisk med ATs DC skal der foretages samme opdatering
i databasen og samme meddelelser til VC skal genereres, men ovenst}ende
meddelelse udelades.
Opdatering af databasen i VCs DC omfatter 2 ting:
1. ATs indgang i VCs AT-adressetabel slettes.
2. I VCs AT-TS-tabel foretages f|lgende opdatering:
Hvis datadelen angiver et 0 for AVC (dvs. AT har
denne VC som AVC), t{lles 1 ned i feltet antal AT
(AVC), ellers t{lles 1 ned i feltet antal AT (PVC).
Hvis begge felter herefter indeholder 0, slettes
hele indgangen.
3. Hvis denne VC er PVC, skal der t{lles 1 ned i AVC-
tabellen for hver AVC. Hvis denne VC er AVC, skal
der t{lles 1 ned i PVC-tabellen ved PVC.
S} oprettes f|lgende meddelelse til VC
til opdatering af AT-TS-tabellen:
Modtageradresse = VC-adresse
Afsenderadresse = VCs DC-adresse
Operationskode = 10.4
Datadel = 0 (= afmelding)
ATs TS-adresse
0/1/2
0/1/2 i datadelen beskriver opdateringen i VCs AT-TS-tabel i TS:
0 : TS-type s{ttes til 0. Sendes hvis antal AT(PVC)
= 0 og antal AT(AVC)> 0.
1 : TS-type s{ttes til 1. Sendes hvis antal AT(PVC)>
0.
2 : Slet indgangen i AT-TS-tabellen. Sendes hvis den
tilsvarende indgang p} DC blev slettet.
Ud over opdateringen i AT-TS-tabellen,
skal indgangen for denne AT slettes i VCs AT-adressetabel (dog kun hvis
VC er af type AT, idet VCer af type IT ikke har en AT-adressetabel
i TS).
Dette g|res gennem meddelelsen:
modtageradresse = VC-adresse
afsenderadresse = VCs DC-adresse
operationskode = 10.2
datadel = 0 (= fjernelse)
AT-adressetabel-indgang
Denne sletning skal ogs} foretages hos de VC(AT)er, som vagten kan
overf|res til, hvorfor samme meddelelse m} sendes til hver af disse
VC(AT)er.
Alle disse 10.2- og 10.4-meddelelser til vagtcentraler kvitteres
til afsender-DCen med 10.3- hhv. 10.5-meddelelser. Efter at have
modtaget alle kvitteringer sender denne DC en 10.5-kvittering
til ATs DC:
Modtageradresse = ATs DC-adresse
Afsenderadresse = VCs DC-adresse
Operationskode = 10.5
Datadel = 0 (= afmelding)
ATs TS-adresse
0/1/2
Meddelelsen til ATs DC afleveres til UTIL, der opsamler
kvitteringer for alle udsendte 10.4-meddelelser og desuden
6.9-kvitteringen fra ATs TS.
N}r alle kvitteringer er indkommet afleveres en af dem (10.5 eller 6.9)
til OPT, hvor den skal give anledning til udskriften:
AT nedlagt: "AT-adresse".
>a1 NEDL[GGELSE AF VC.
Nedl{ggelse af en VC foreg}r fra operat|rkonsollen p} VCs DC
efter bestilling fra vagtcentralen.
Den systemm{ssige nedl{ggelse foruds{tter, at vagtcentralen ikke er prim{r vagtcentral
for nogen AT, at vagt ikke er overf|rt til eller fra andre vagtcentraler,
og at vagtcentralen selv accepterer nedl{ggelsen.
Proceduren aktiveres ved indtastning p} konsollen af:
Nedl{g VC: "VC-adresse";
Kommandoen fortolkes af OPT og afleveres til UTIL som meddelelsestypen
"anmodning om nedl{ggelse af VC":
Modtageradresse = VC-adresse
Afsenderadresse = VCs DC-adresse
Operationskode = 7.2
Datadel = tom
UTIL unders|ger, om den angivne adresse er lovlig, dvs. at adressen
er en VC-adresse, at denne VC eksisterer, og at VC ligger under denne
DC. Desuden unders|ges det, at VC ikke er prim{r vagtcentral for
nogen AT (iflg. VCs AT-adressetabel) og ikke for tiden indg}r i en vagtflytning.
Disse unders|gelser kan resultere i {ndring af operationskoden til
15.10 ved ulovlig adresse eller 15.8, hvis VC er PVC for mindst
een AT. Hvis dette sker, afleveres meddelelsen til OPT, der udskriver
Ulovlig adresse
eller
"VC-adresse" er prim{r vagtcentral
Desuden skal det sikres,
dvs. at der ikke er overf|rt vagt fra eller til denne VC, hvilket ses i VCaVCm-tabellen. Hvis
der er overf|rt vagt inds{ttes 15.7 i operationskoden, og i datadelen
inds{ttes et 0, hvis vagten er overf|rt til en anden VC, og et 1,
hvis vagten er overf|rt fra en eller flere VCer. Dette udskrives
p} konsollen:
Vagt overf|rt til/fra anden VC
>a2 Anmodning om nedl{ggelse
Hvis ingen af disse fejludskrifter benyttes, skal der indhentes
accept til nedl{ggelsen fra VC. Meddelelsen sendes til VC, der
skal kvittere med:
Modtageradresse = VCs DC-adresse
Afsenderadresse = VC-adresse
Operationskode = 7.3
Datadel = 0 = ikke accept, 1 = accept
Denne meddelelse afleveres til UTIL, der ved aflevering af en kopi
heraf til OPT s|rger for udskrivning til operat|ren:
nedl{ggelse af "VC-adresse" (ikke) accepteret
Hvis nedl{ggelsen ikke accepteres, standses her.
>a2 Afmelding af ATer
Hvis den accepteres, skal det nu unders|ges, om VC er AVC for nogle
ATer. I s} fald skal der foretages afmelding af disse, og deres PVCer
skal have besked.
Hvis VC er af type AT, og VC kan overf|re vagt til andre VC(AT)er,
skal denne VCs egne ATer fjernes fra VCernes AT-adressetabeller.
VCs PVC-tabel angiver, hvilke vagtcentraler, som skal have besked.
Til hver PVC i PVC-tabellen sendes en "meddelelse om nedl{ggelse
af AVC:
Modtageradresse = PVC-adresse
Afsenderadresse = VCs DC-adresse
Operationskode = 6.10
Datadel = VC-adresse
Logmeddelelsen til PVCs DC af denne 6.10-meddelelse skal resultere
i en {ndring i denne PVCs AVC-tabel, idet indgangen for denne AVC
slettes. Hvis PVCs DC er identisk med AVCs DC foretages {ndringen
i stedet ved afsendelse af 6.10-meddelelsen.
Herefter sendes besked til alle VCens ATer om afmeldingen af
AT-AVC-forbindelsen. Til hver AT sendes en "meddelelse om opdatering
af VC-adressetabel":
Modtageradresse = AT-adresse
Afsenderadresse = VCs DC-adresse
Operationskode = 10.0
Datadel = 2 (=slet indgang)
VC-adresse-tabel-indgang
Meddelelsen skal resultere i, at alle indgange i ATens VC-adressetabel
med denne VC-adresse skal fjernes.
Hvis ATs DC = VCs DC skal samme {ndring foretages i DCs database
umiddelbart f|r eller efter afsendelsen af denne meddelelse. Ellers
skal logmeddelelsen til AT's DC resultere i denne {ndring i databasen
i ATs DC.
AT kvitterer med:
Modtageradresse = VCs DC-adresse
Afsenderadresse = AT-adresse
Operationskode = 10.1
Datadel 2 = slet AVC;
VC-adresse-tabel-indgang
Hvis VC er af type AT, og VC kan overf|re vagt til andre VC(AT)er,
st}r VCs egne ATer opf|rt i disse VC(AT)ers AT-adressetabel, og de skal
nu fjernes.
Derfor sendes en 10.2-meddelelse (opdatering af AT-adressetabel) for
hver VCs egne ATer til hver af de vagtcentraler af type AT, der kan
modtage vagt (VCm(AT)-tabelindgange) med 1 i modtagerfeltet, hvor
VCm er af type AT). Disse meddelelser kvitteres med 10.3-meddelelser.
Logmeddelelserne 0.0-10.2 resulterer i tilsvarende {ndringer p} DC.
>a2 Afmelding af vagtflytteordninger
Herefter skal der sendes meddelelser til de vagtcentraler, der er
vagtflytteordning med.
Der gives besked til alle vagtcentraler i VCa-tabellen for denne
VC, dvs. alle vagtcentraler, der kan overf|re vagt til denne VC:
Modtageradresse = VC-adresse fra VCa-tabel
Afsenderadresse = denne VCs DC-adresse
Operationskode = 10.6
Datadel = 0(=sletning)
VC-adresse p} denne VC
Dette skal resultere i fjernelse af denne VC i de p}g{ldende VCers
VCm(AT)- eller VCm(IT)-tabel. Samme {ndring skal naturligvis afspejles
i VCm(AT)- eller VCm(IT)-tabellen p} DC: Hvis modtageradressen h|rer
ind under afsender-DCen, foretages {ndringen i forbindelse med afsendelsen
af 10.6-meddelelsen. Ellers foretages {ndringen p} grundlag af
logmeddelelsen til modtagers DC.
Der kvitteres til denne VCs DC:
Modtageradresse = denne VCs DC-adresse
Afsenderadresse = VC-adresse fra VCa-tabel
Operationskode = 10.7
Datadel = 0
VC-adresse p} denne VC
Desuden gives besked til de vagtcentraler, der kan f} overf|rt
vagt fra den VC, der nu skal nedl{gges.
Hvis denne VC er af type AT, skal der nu gives besked til alle de
vagtcentraler fra denne VCs VCm(AT)-tabel, der vil modtage vagt
herfra (kun en delm{ngde af tabellens indgange). Hvis VC er af
type IT sendes besked til
>ul
alle
vagtcentraler i denne VCs VCm(IT)-tabel. Beskeden best}r i en
"anmodning om opdatering af VCa-tabel":
Modtageradresse = VC-adr. fra VCm(AT)-/VCm(IT)-
tabel
Afsenderadresse = denne VCs DC-adresse
Operationskode = 9.6
Datadel = 0 = sletning
VC-adresse
Vagtcentralen kan ikke mods{tte sig denne sletning, men f}r blot
besked herom. Der findes ikke nogen VCa-tabel i TS - opdateringen
skal foretages i den p}g{ldende VCs VCa-tabel i DC. Hvis de to
vagtcentralers DCer er identiske, foretages sletningen ved
afsendelse af 9.6-meddelelsen, ellers foretages den p} grundlag
af logmeddelelsen herfor til modtageradressens DC.
Desuden resulterer meddelelsen i, at denne VC slettes i VCm(AT)-tabellen
(i TS og DC), hvis den VC, der modtager meddelelsen er af type AT.
Fra vagtcentralen kvitteres med meddelelsen:
Modtageradresse = denne VCs DC-adresse
Afsenderadresse = VC-adr. fra VCm(AT)-/VCm(IT)-
tabel
Operationskode = 9.7
Datadel = 0 = sletning
VC-adresse
>a2 Nedl{ggelse af vagtcentralen selv
S} foretages selve nedl{ggelsen. Der sendes "meddelelse om
nedl{ggelse af VC":
Modtageradresse = VCs TS-adresse
Afsenderadresse = VCs DC-adresse
Operationskode = 7.4
Datadel = VC-adresse
Dette resulterer i {ndringer i TS. Lignende {ndringer skal foretages
p} DC ved afsendelsen. Disse best}r i at fjerne al information om VC
fra databasen, dvs. VC-beskrivelsen, AT-adressetabel, AT-TS-tabel,
VCa-tabel og VCm(AT)- eller VCm(IT)-tabel (afh{nger af om VC er af
type AT eller IT), PVC- og AVC-tabel. Desuden fjernes aktuel
VCe-tabel (aktuel VCm og krypteringsn|gle ligger i VC-beskrivelsen).
Der sendes kvittering til DC:
Modtageradresse = VCs DC-adresse
Afsenderadresse = VCs TS-adresse
Operationskode = 7.5
Datadel = VC-adresse
Denne meddelelse afleveres til OPT, der udskriver p} konsollen:
VC nedlagt: "VC-adresse".
>a1 INTERN TEST AF ATer.
Intern test af en AT (herunder ogs} en VC af type AT) kan foretages
fra konsollen i DC, hvorimod ekstern test ikke kan udf|res fra DC.
DC kan kun teste ATer i eget distrikt.
Operat|ren indtaster MML-kommandoen:
Intern test 1 : "AT- eller VC(AT)-adresse";
eller
Intern test 2 : "AT- eller VC(AT)-adresse";
MML-kommandoen fortolkes af operat|rmodulet og afleveres til
utilitymodulet.
Intern test 1 kan foretages p} alle AT'er mens intern test 2 kun
m} foretages p} ATer med parallelmodul (PAM).
Utilitymodulet checker om den indtastede adresse h|rer ind under
den p}g{ldende DC, og angiver en AT eller VC(AT). Hvis
der er bedt om intern test 2 checkes, at den p}g{ldende AT har
parallelmodul. Hvis adressen ligger uden for distriktscentret
eller fx angiver en VC af type IT udskrives p} konsollen:
Ulovlig adresse
Hvis der er bedt om intern test 2 af en AT uden parallelmodul,
udskrives p} konsollen:
Ulovlig intern test 2
Hvis AT-adressen og testformen er lovlig, skal f|lgende meddelelse
sendes til den aktuelle AT-adresse:
Modtageradresse = AT eller VC-adresse
Afsenderadresse = DC-adresse
Operationskode = 8.0/8.2
Datadel = tom
Operationskode 8.0 bruges ved intern test 1, mens intern test 2 bruger
8.2. N}r testen er udf|rt, sendes resultatet heraf til DC (OPT),
hvorefter det udskrives p} konsollen.
Resultatet til DC:
Modtageradresse = DC-adresse
Afsenderadresse = AT- eller VC-adresse
Operationskode = 8.1/8.3
Datadel = 0/1
Resultatet af intern test 1 sendes med operationskode 8.1, mens
resultatet af intern test 2 sendes med operationskode 8.3. Et
0 i datadelen angiver, at testen er g}et godt, mens et ettal angiver
fejl i AT.
>a1 START OG STOP POLL AF AT.
Start og stop poll af AT udf|res altid af ATs DC
i samarbejde med prim{r vagtcentral.
Start poll kan aktiveres enten fra operat|rkonsollen gennem OPT
(efter fejlretning) eller fra UTIL ved oprettelse af en AT.
Stop poll kan aktiveres enten fra operat|rkonsollen gennem OPT
eller fra errorhandler. Aktivering fra errorhandler er beskrevet
i SP.DCSYS.5/2.
Aktivering fra OPT af start eller stop poll indledes med, at
operat|ren indtaster:
Stop/start poll af AT: "AT-adresse";
OPT overs{tter denne kommando til en DC-tilladelse til stop eller start poll:
Modtageradresse = -
Afsenderadresse = DC-adresse
Operationskode = 6.4
Datadel = AT-adresse
0/1
0 i datadelen angiver stop poll, 1 angiver start poll.
Denne meddelelse afleveres til UTIL, der sender den til
fra PVC. Dog checkes f|rst, om AT-adressen er lovlig. Dette
foreg}r som under nedl{ggelse af AT.
UTIL skal inds{tte modtageradresse, som skal v{re alarmnetadressen p} ATs PVC.
Denne findes ved opslag i den p}g{ldende ATs VC-adressetabel
og herefter i VCaVCm-tabellen.
Efter inds{ttelse af
modtageradresse sendes meddelelsen afsted.
Fra PVC sendes en meddelelse (PVC-tilladelse), hvor datadelen angiver,
om polling m} stoppes/startes:
>ne 6
Modtageradresse = ATs DC-adresse
Afsenderadresse = PVC-adresse
Operationskode = 6.5
Datadel = AT-adresse
0/1
0/1
F|rste 0/1 i datadelen angiver stop/start, mens n{ste 0/1 angiver
afslag/tilladelse.
Meddelelsen afleveres i DC til UTIL, der s|rger for udskrivning
p} konsollen gennem OPT:
stop/start poll af "AT":
accepteret/afsl}et
Stop poll af AT skal ogs} kunne udf|res, n}r der ikke er forbindelse
til PVC, men vil altid starte med et fors|g p} afsendelse af
6.4-meddelelsen til PVC.
Dvs. at en meddelelse fra nettet om, at 6.4-meddelelsen ikke
kan n} frem, f}r samme konsekvens som en accept fra vagtcentralen,
bortset fra konsoludskriften, der vil indeholde ordet
"returneret" i stedet for "accepteret".
Hvis der herigennem er givet tilladelse til stop/start poll fra
b}de DC og prim{r vagtcentral, sendes nu automatisk en ordre om
stop/start poll til AT-connector.
>ne 4
Modtageradresse = AT-adresse
Afsenderadresse = ATs DC-adresse
Operationskode = 9.0
Datadel = 0/1
initialv{rdi af transmissions-
fejlt{ller
poll interval
0 i datadelen angiver stop poll, 1 angiver start poll.
Denne meddelelse resulterer i en tabel{ndring i ATs TS, idet
AT-tabellen for den p}g{ldende TS skal {ndres, s} indgangen
for denne AT i poll-feltet indeholer 0 ved stop poll og 1 ved start
poll. Denne {ndring skal ogs} foretages i DCs database.
Efter poll af AT er stoppet eller startet, sendes kvittering tilbage
til DC:
Modtageradresse = ATs DC-adresse
Afsenderadresse = AT-adresse
Operationskode = 9.1
Datadel = 0/1
initialv{rdi for transmissions-
fejlt{ller
poll interval
Datadelen er en gentagelse af datadelen fra 9.0.
Meddelelsen afleveres til OPT, hvor den resulterer i udskriften:
Poll stoppet/startet : "afsenderadresse"
>a1 START POLL AF VC.
Start poll af VC aktiveres fra operat|rkonsollen gennem OPT p} VCs DC.
Operat|ren indtaster:
Start poll af VC : "VC-adresse";
Kommandoen overs{ttes til:
Modtageradresse = VC-adresse
Afsenderadresse = VCs DC-adresse
Operationskode = 9.0
Datadel = 1
og afleveres til UTIL.
Efter adressecheck sendes meddelelsen til VC. Meddelelsen vil her
medf|re en tabel{ndring og denne {ndring skal ogs} foretages p} DC.
VC-tabellen for VCs TS skal {ndres, s} indgangen for denne VC
indeholder 1 i poll-feltet.
Efter udf|relse af operationen p} VC med udskrivning herom til VC,
kvitteres til OPT p} DC:
Modtageradresse = VCs DC-adresse
Afsenderadresse = VC-adresse
Operationskode = 9.1
Datadel = 1
OPT udskriver:
Poll startet: "afsenderadresse"
>a1 SERVICEPOLL
Der har vist sig at v{re behov for en ny facilitet til fejlfinding
- servicepoll.
Servicepoll indbefatter med normal rate, men uden rapportering af
AT-svar hhv. VC(AT)-svar til DC, VCer eller ATer. Dvs. at
protokollen mellem AT-connector og AT (hhv. VC(AT)-connector og
VC(T)) k|res p} normal vis, men der foretages ikke nogen videresendelse
til AT-handler (hhv. VC-handler).
Servicepoll er aktuel ved aftestning af en fejlbeh{ftet kommunikation
mellem TS og AT (VC(AT)) og ved aftestning af en AT (VC(AT)) under
oprettelse.
>a2 Servicepoll af AT
Start af servicepoll af en AT kan kun foreg} fra ATens DC og kr{ver,
hvis AT polles, tilladelse fra ATs PVC.
Efter servicealarm, stop-poll-alarm, liniealarm eller statusalarm
fra en AT kan DC anmode PVC om tilladelse til servicepoll. Denne
procedure er analog til fremgangsm}den ved stop poll.
Ved opn}et tilladelse sendes automatisk meddelelse til AT-connector
om servicepoll, analogt til meddelelsen om stop poll. Returnering
af DC-tilladelsen opfattes som accept.
DC indhenter ikke tilladelse fra PVC til servicepoll af en AT
i f|lgende tilf{lde:
- n}r poll i forvejen er stoppet
- n}r AT er under oprettelse og poll endnu
ikke er startet
I disse tilf{lde resulterer tilladelsen til servicepoll fra operat|ren
p} DC direkte i en meddelelse til AT-connector om servicepoll.
>a2 Servicepoll af VC(AT)
Servicepoll af en VC(AT) kan kun foretages fra VC(AT)s DC og kr{ver
under normale forhold accept fra VC(AT). Hvis poll af VC(AT) er stoppet
eller ved oprettelse af VC(AT) endnu ikke er startet, foretages servicepoll
direkte efter tilladelse fra operat|ren p} DC.
>a1 TAKSERING.
Fra DC foretages automatisk en afl{sning af pakket{llere p} alle
underliggende ATer og VCer een gang i d|gnet.
Der findes en pakket{ller for hver AT og VC i den tilknyttede TS.
Den benyttes til registrering af antal afsendte meddelelser. Hver
gang der afsendes en meddelelse fra en AT eller VC, vil dennes
pakket{ller blive talt op med 1. Opt{llingen sker cyklisk (modulo n).
UTIL opretter og sender meddelelsen:
Modtageradresse = AT eller VC-adresse
Afsenderadresse = DC-adresse
Operationskode = 11.4
Datadel = tom
I ATs eller VCs TS oprettes en kvittering med v{rdien af den p}g{ldende
ATs eller VCs pakket{ller i datadelen:
Modtageradresse = DC-adresse
Afsenderadresse = AT- eller VC-adresse
Operationskode = 11.5
Datadel = pakket{ller
Denne pakket{ller skal benyttes til beregning af den akkumulerede
pakket{ller for den p}g{ldende AT eller VC i databasen p} DC.
Den akkumulerede pakket{ller betegner det antal meddelelser, der er
afsendt fra den p}g{ldende AT eller VC siden sidste afregning. T{lleren
findes som et felt i hver AT- og VC-tabel. Desuden indeholder disse
tabeller et felt "sidste pakket{ller" til brug ved beregning af v{rdien
af den akkumulerede pakket{ller. Sidste pakket{ller indeholder den
sidst afl{ste v{rdi af pakket{lleren i TS.
Beregning af akkumuleret pakket{ller foreg}r s}ledes:
Hvis TS ikke er blevet reloadet siden sidste afl{sning, benyttes v{rdien
af den afl{ste pakket{ller minus v{rdien af sidste pakket{ller. Hvis
denne v{rdi er negativ, adderes n til v{rdien. Den fremkomne v{rdi
adderes til den akkumulerede pakket{ller, og resultatet udg|r den
nye v{rdi af den akkumulerede pakket{ller. Desuden inds{ttes v{rdien
af den afl{ste pakket{ller i sidste pakket{ller.
Hvis TS er blevet reloadet siden sidste afl{sning, er pakket{lleren
herved blevet nulstillet. Det medf|rer, at antal afsendte meddelelser
fra sidste afl{sning indtil (seneste) reload er g}et tabt og kan derfor
ikke medtages i beregningen. Pakket{ller indeholder s} det antal
meddelelser, der er afsendt siden reload indtil denne afl{sning. Denne
v{rdi adderes til den akkumulerede pakket{ller og resultatet inds{ttes
som ny v{rdi af den akkumulerede pakket{ller. Desuden inds{ttes v{rdien
af den afl{ste pakket{ller i sidste pakket{ller.
Taksering foretages ud fra den akkumulerede pakket{ller, hvorefter denne
nulstilles.
Den beskrevne fremgangsm}de kr{ver, at DC holder regnskab med, om de
enkelte TSer er blevet reloadet siden sidste afl{sning. Dette kan
f.eks. ske ved at registrere tidspunkt for sidste reload og tidspunkt
for sidste afl{sning af pakket{llere for hver TS.
>a1 OPDATERING AF GR[NSER.
Det er muligt fra operat|rkonsollen at {ndre servicegr{nse, stop poll
gr{nse og det maksimale antal successive liniefejl, man vil acceptere,
for en AT eller VC.
Servicegr{nsen for en AT eller VC {ndres ved at
indtaste f|lgende fra operat|rkonsollen:
Servicegr{nse: "AT eller VC", "antal";
OPT vil overs{tte en s}dan kommando til meddelelsen:
Modtageradresse = AT- eller VC-adresse
Afsenderadresse = DC-adresse
Operationskode = 11.6
Datadel = antal
Meddelelsen overgives til utility-modulet, der checker, at den angivne
AT eller VC eksisterer under denne DC, og at antallet er positivt og st|rre
end det startpunkt, der benyttes som initialv{rdi for transmissionsfejlt{lleren.
Hvis parametrene ikke godkendes, inds{ttes 15.10 (ved ulovlig adresse)
eller 15.11 (ved uacceptabelt antal) i operationskoden, og meddelelsen
overgives til OPT til fejludskrift p} konsollen.
Ved godkendelse af parametrene afsendes meddelelsen. Da denne
meddelelse vil resultere i en tabel{ndring i TS, skal en tilsvarende
{ndring foretages i DC. I AT-, VC(AT)- eller VC(IT)-tabellen s{ttes feltet
servicegr{nse til at indeholde det indtastede antal.
Efter behandling i TS returneres kvitteringen:
Modtageradresse = DC-adresse
Afsenderadresse = AT- eller VC-adresse
Operationskode = 11.7
Datadel = antal
Datadelen her er en gentagelse af datadelen i 11.6-meddelelsen.
I DC afleveres kvitteringen til OPT, der s|rger for udskriften:
Servicegr{nse for "AT eller VC" {ndret til "antal".
En stop poll gr{nse {ndres ved indtastning p} opert|rkonsollen af:
stop poll gr{nse: "AT eller VC", "antal";
Denne kommando overs{ttes til en meddelelse som vist ved {ndring af
servicegr{nse, blot med operationskode 11.10. Der udf|res samme
check af denne meddelelse, men der kr{ves desuden, at stop poll
gr{nsen er st|rre end servicegr{nsen. Proceduren foreg}r i|vrigt
analogt til det ovenfor beskrevne. Operationskoden i kvitteringen
er 11.11.
Det maksimale antal acceptable liniefejl i tr{k for en AT eller VC
angives ved
max succ lin fejl: "AT eller VC", "antal";
Denne kommando overs{ttes t
modtageradresse = AT- eller VC-adresse
afsenderadresse = DC-adresse
operationskode = 11.12
datadel = "antal"
Meddelelsen overgives til utility-modulet, der checker adressen,
og at antallet er st|rre end 0. Hvis meddelelsen er acceptabel,
{ndres feltet max succ lin fejl i AT-, VC(AT)- eller VC(IT)-tabellen
og meddelelsen sendes.
Der kvitteres med
modtageradresse = DC-adresse
afsenderadresse = AT- eller VC=adresse
operationskode = 11.13
datadel = "antal"
>a1 KRYPTERINGSN\GLER.
Ved oprettelse af ATer og VCer, der |nsker kryptering, udskrives
en krypteringsordre, der overgives til operat|ren ved DC. Denne
krypteringsordre skal angive alarmnetadressen p} den AT eller VC, der
|nsker kryptering.
Operat|ren skal herefter s|rge for oprettelse af krypteringsn|gle.
Krypteringsn|glen skal opbevares 3 steder: i DCs database, i
AT- eller VC-connector, i TS og desuden skal den br{ndes ind i en
ROM. Dette foreg}r i ROM-br{nderen tilsluttet DCs RC8302, hvorefter den skal
indg} i krypteringschippen i ATen hos abonnenten eller vagtcentralen.
Oprettelsen foreg}r ved at operat|ren s{tter en ROM i ROM-br{nderen
og indtaster p} hovedkonsollen:
Krypteringsn|gle: "AT- eller VC-adresse";
Kommandoen overs{ttes til en meddelelse med operationskode 10.8
og AT- eller VC-adressen som modtager.
Denne meddelelse afleveres til UTIL.
UTIL benytter en tilf{ldigtalstalsgenerator til at generere en
krypteringsn|gle p} 56 bit, hvorefter der p}s{ttes 8 checkbit,
s} krypteringsn|gle bliver p} ialt 64 bit. Disse inds{ttes i
datadelen i meddelelsen sammen med et 1-tal, der skal angive
inds{ttelse af krypteringsn|gle (0 i datadelen af denne meddelelse
angiver sletning af krypteringsn|gle, mens 2 angiver {ndring).
Herudover genereres et l|benummer. For at sikre entydighed af disse
l|benumre genereres disse fortl|bende (p} hvert distriktscenter),
og tilf|jes herefter distriktscentrets nummer. Dvs. i DC 3 genereres
l|benumrene 13, 23, 33, 43 osv.
Krypteringsn|gle og l|benummer inds{ttes i AT- eller VC(AT)-tabellen
i databasen og 10.8 meddelelsen sendes ud til AT- eller VC-connector.
Desuden br{ndes krypteringsn|glen ind i ROM'en. Samtidigt udskrives
p} en printer l|benummeret og enten AT-adressen tillige med
adressen p} ATs PVC eller VC-adressen.
N}r opdateringen er foretaget i TS, sendes kvittering til DC:
Modtageradresse = DC
Afsenderadresse = AT eller VC
Operationskode = 10.9
Datadel = 1 (= inds{ttelse)
krypteringsn|gle
Kvitteringen afleveres til UTIL.
N}r 10.9 kvitteringen er modtaget og printerudskriften og br{ndingen
er foretaget, afleveres kvitteringen til OPT, hvilket resulterer i
konsoludskriften:
Krypteringsn|gle genereret: "AT- eller VC-adresse"
Operat|ren udleverer printerudskriften med l|benummer og
AT-adresse og/eller VC-adresse h{ftet sammen med ROM'en,
til vagtcentralen.
>a1 ABONNENTOPLYSNINGER.
Hvis prim{r vagtcentral for en AT er af type IT, kan PVC afkr{ve
ATs DC en beskrivelse af AT
ved at sende meddelelsen:
Modtageradresse = ATs DC-adresse
Afsenderadresse = PVC-adresse
Operationskode = 9.10
Datadel = AT-adresse
I DC afleveres meddelelsen til UTIL, der gennem opslag i databasen
finder f|lgende oplysninger om AT:
navn,
adresse,
+/- parallelmodul
+/- kryptering
VC-adressetabel
Disse oplysninger stilles op p} forst}elig form og sendes herefter
ud til PVC via en generel meddelelse:
Modtageradresse = PVC-adresse
Afsenderadresse = ATs DC-adresse
Operationskode = 9.8
Datadel = tekststreng indeholdende
oplysninger om AT
«eof»