|
DataMuseum.dkPresents historical artifacts from the history of: RC4000/8000/9000 |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about RC4000/8000/9000 Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - download
Length: 62976 (0xf600)
Types: TextFile
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◀