|
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: 64512 (0xfc00)
Types: TextFileVerbose
Names: »brufu«
└─⟦a41ae585a⟧ Bits:30001842 SW-save af projekt 1000, Alarm-system
└─⟦72244f0ef⟧
└─⟦this⟧ »brufu«
>fo @~SP.SYS.3/2~@
>a1 INTRODUKTION.
Form}let med denne brugs- og funktionsbeskrivelse (BRUFU) er at give
en samlet oversigt over alarmsystemets funktioner samt deres anvendelse.
BRUFUen henvender sig til
>ul
alle,
der |nsker en beskrivelse af hvilke funktioner, systemet
indeholder.
I dette kapitel pr{senteres - ud over en oversigt over hele
alarmsystemet - dels de enkelte komponenter, der udg|r alarmsystemet,
dels hvorledes sammenh{ngen er mellem dem.
Endelig gives en kort oversigt over systemets funktioner. Disse vil
blive udf|rligt behandlet i de senere kapitler.
>a2 Oversigt
Form}let med alarmsystemet er at muligg|re transmission af alarmer fra
(telefon-)abonnenter til vagtcentraler samt transmission af styringer
den modsatte vej.
Tilslutningen til systemet er overv}get og sker p}
abonnentstr{kningen p} samme ledning som bruges til almindelig
telefoni.
>ne24
Alarmsystemets funktion illustreres af f|lgende figur:
>sp22
>fg Funktion
P} alle telefoncentraler med alarmabonnenter placeres en datamaskine
- en s}kaldt terminalstation (TS). Denne s|rger for overv}gningen
af abonnentstr{kningen samt opsamling og videresendelse af alarmer
og styringer.
Alarmsystemet benytter et datanet, der er opbygget parallelt med
telefonnettet. Dette datanet benytter datamaskiner placeret dels
p} telefoncentralerne (TS), og dels p} netgruppecentre (NC) og
distriktscentre (DC).
>a2 Alarmsystemets komponenter
I dette afsnit vil vi se n{rmere p} hvilke komponenter, alarmsystemet
best}r af.
I systemet indg}r f|lgende dele:
>ne 10
- alarmudstyr (AU)
- alarmterminal (AT)
- AT vagtcentral (VC(AT))
- intelligent vagtcentral (VC(IT))
- terminalstation (TS)
- netgruppecenter (NC)
- distriktscenter (DC)
- ekspeditionsterminaler
- X.25 datanet (PAXNET)
>a3 Alarmudstyr (AU)
Dette er abonnentens centralskab incl. diverse alarmsl|jfer
(vinduesoverv}gning, r|gmeldere osv.) samt signalgivere for styringer
(start af sprinkleranl{g, lukning af brandd|re osv).
AU leveres af private
vagtfirmaer. AUen er i stand til at kommunikere med
alarmterminalen.
Abonnentens alarmudstyr har selv mulighed for at v{lge til hvilken
vagtcentral eller brandstation en given alarm skal sendes, og om
den eventuelt skal sendes til flere modtagere.
Det skal imidlertid p} forh}nd aftales med vagtcentralen, at den kan
modtage alarmer fra den p}g{ldende abonnent.
>a3 Alarmterminal (AT)
Abonnenter sluttes p} alarmnettet ved hj{lp af en alarmterminal.
Alarmterminalen kan p} den ene side v{re tilsluttet en AU og til
den anden side telefonlinien.
AT danner skillefladen mellem abonnentens udstyr og alarmsystemet.
AT installeres hos abonnenten og varetager s}vel kommunikationen med
nettet som kommunikation med AUen.
AT fremstilles i fire udgaver:
ATIS: Indbygningskort med seriel interface (SERIF)
ATIP: Indbygningskort med parallel interface (PARIF)
ATS : Kabinetversion med seriel interface (SERIF)
ATP : Kabinetversion med parallel interface (PARIF)
Kabinetversionerne kan {ndres til:
AT/AU: Kombineret alarmterminal og alarmudstyr.
Udvekslingen af information mellem alarmterminalen og terminalstationen
sker over abonnentens normale telefonlinie ved hj{lp af en s{rlig
teknik (8KHz udenb}ndssignalering), hvorved signalet i den ene ende overlejres tale-signalet
og i den anden ende filtreres fra igen.
Det er s}ledes muligt at benytte linien til almindelig taleoverf|ring
>ul
samtidig
med, at den bruges til alarmtransmission.
Abonnenten beh|ver imidlertid ikke at have telefon for at kunne
tilsluttes alarmnettet (men telefonlinien skal naturligvis etableres).
Hvis alarmterminalen er en kabinetversion, monteres den hos abonnenten i en sikret kasse med egen
str|mforsyning og 24-timers n|dstr|mreserve.
>a3 Vagtcentraler
En vagtcentrals hovedopgave er at modtage abonnentalarmer fra
abonnentens AU og pr{sentere dem for en operat|r.
De databytes, alarmen best}r af, kan indeholde detaljeret information
om alarmens type, hvor i bygningen den er opst}et osv. Det er imidlertid
op til det enkelte vagtselskab at definere hvilken betydning, de
forskellige alarmkoder skal have.
Vagtcentralen har til enhver tid mulighed for at sende en styring til
AUen hos en af sine egne abonnenter. Ogs} disse styringer kan
till{gges forskellig betydning, fx
- lukning af brandd|re
- aktivering af sprinkleranl{g
- fjernbetjening af pumpestationer
etc.
For en given abonnent kan der godt eksistere flere vagtcentraler (fx
privat vagtcentral, olieselskab, brandstation osv.).
Af disse har een s{rlig status. Den kaldes den
>ul
prim{re vagtcentral
(PVC). Det vil typisk v{re PVC, der har leveret abonnentens AU.
De |vrige vagtcentraler kaldes
>ul
alternative vagtcentraler
(AVC).
Ogs} AVC har mulighed for at sende styringer til AU. Dette kr{ver
dog at den har f}et tildelt status som styrende AVC i forhold til
den givne abonnent.
PVC modtager kopi af alle alarmer, der sendes til AVC.
Vagtcentraler kan tilsluttes alarmsystemet p} to m}der afh{ngig
af abonnentantallet, nemlig som
- AT-vagtcentral eller som
- intelligent vagtcentral.
>a4 AT-vagtcentral (VC(AT))
Sm} vagtcentraler (op til 256 abonnenter) kan tilsluttes p} samme m}de
som centralskabet hos abonnenterne, nemlig via en alarmterminal.
En vagtcentral tilsluttet p} denne m}de kaldes en VC(AT).
Informationen, der kommer fra terminalstationen, er nu alarmer (med
identifikation af den abonnent, der sendte den) og informationen,
som vagtcentralen sender, er styringer af abonnentens AU.
Tilslutning p} denne m}de kr{ver blot en betjeningspult eller en datask{rm
til at vise,
hvilke alarmer, der kommer (og fra hvem) samt til indtastning af
kommandoer.
Abonnenterne identificeres ved hj{lp af koder (0 til 255), b}de
ved pr{sentationen af alarmer p} betjeningspulten og ved afsendelse af
styring.
Benyttes en datamaskine som VC(AT) kan VC(AT) eventuelt selv transformere abonnentkoden
til abonnentens navn og adresse.
>a4 Intelligent vagtcentral (VC(IT))
St|rre vagtcentraler tilsluttes TS direkte (fx via en V.24 modem
forbindelse med 1200 bps).
En s}dan tilslutning indeb{rer mulighed for at h}ndtere et vilk}rligt
stort antal alarmabonnenter.
Det skal dog understreges, at ogs} vagtcentraler med f} abonnenter
kan tilsluttes p} denne m}de.
Endvidere er der mulighed for at overf|re tekst-information til
en VC(IT).
Abonnenter identificeres ved hj{lp af 9-cifrede "alarmnetadresser".
>a3 Terminalstation (TS)
TS p} telefoncentralen er en datamaskine (RC3502). Den udg|r alarmsystemets
forbindelse til s}vel abonnenter (ATer) som vagtcentraler (af
s}vel type AT som type IT).
TS overv}ger konstant forbindelsen til de tilsluttede ATer, idet
de POLLes med faste intervaller.
Samtidig er TS en knude i datanettet.
>a3 Netgruppecenter (NC)
NC er den datamaskine (RC3502), der st}r p} telefonnettets netgruppecenter.
NC er en knude i datanettet.
NC virker som samleknude for TSerne i en netgruppe (op til 64).
NCs opgave er at overv}ge forbindelsen til de underliggende TSer
og afgive net-alarm til DC, hvis forbindelsen forsvinder.
>a3 Distriktscenter (DC)
DC er en st|rre datamaskine, der er anbragt i tilknytning til
telefonnettets distriktscenter. Det er fra DC den underliggende
del af alarmnettet overv}ges.
I det f|lgende vil forkortelsen "DC" blive brugt om selve
datamaskinen p} distriktscentret, mens udtrykket "distriktscenter"
vil blive brugt om lokationen.
DC omfatter en database med oplysninger om de tilsluttede
abonnenter og vagtcentraler.
DC modtager kopi af alle datapakker, der sendes i alarmsystemet.
Disse gemmes p} DCs disc (de "logges").
DC best}r af en RC8000 med 2 disce, magnetb}ndstation, printer, hovedkonsol
og operat|rkonsol. Herudover findes en RC3502 front-end, der
udg|r tilslutningen til PAXNET.
>ne32
Konfigurationen er f|lgende:
>sp30
>fg DC konfiguration.
>ul
Discene
bruges som baggrundslager for programmer og database. Selve databasen
beslagl{gger een af de fysiske disce.
>ul
Magnetb}ndstationen
bruges til sikkerhedskopiering af databasen samt ved dumpning af
log-filen.
>ul
Printeren
bruges ved udskrifter fra databasen og log-filen samt til udskrift
af ordresedler o.l. til installationskontoret.
>ul
Hovedkonsollen
bruges til kommunikation med RC8000s monitor og operativsystem.
>ul
Operat|rkonsollen
bruges til kommunikation med alarmsystemets applikationer i RC8000.
Kommandoerne p} operat|rkonsollen gives i MML (Man Machine Language
if|lge CCITTs rekommendationer Z.311 til Z.359).
>a3 Ekspeditionsterminal
I tilknytning til DC findes en ekspeditionsterminal hvorfra
oplysninger om nye abonnenter og vagtcentraler indtastes
i systemet. Ogs} {ndringer indtastes herfra.
Kommunikationen er formatorienteret, dvs. der s{ttes hele
sk{rmbilleder ("formularer") op. Disse indeholder
fortrykte tekster samt felter til at indtaste de |nskede oplysninger.
>a3 PAXNET
Forbindelsen mellem systemets forskellige datamater
(TS, NC og DC) varetages af PAXNET.
PAXNET er et X.25/3 packet switching datanet efter CCITTs
rekommendationer.
Forbindelserne mellem PAXNET-knuder kan v{re HDLC-forbindelser med
PCM-transmission (Pulse Code Modulation). Overf|ringshastigheden p}
disse linier er 64Kb/s.
Alarmsystemets tilslutning til PAXNET sker ved hj{lp af en X.25
DTE-tilslutning (Data Terminal Equipment).
S}ledes ligger alarmsystemets programmel og PAXNETs programmel i de samme
fysiske maskiner, men deres software interfaces muligg|r, at de kan adskilles
i hver sin maskine.
>ne25
>a2 Alarmnettets struktur
Alarmnettet er hierarkisk opbygget:
>sp 20
>fg Alarmnettets struktur.
Det skal understreges, at alarmsystemets struktur ("topologi") ikke n|dvendigvis
falder sammen med topologien for PAXNET. S}ledes kan PAXNET indeholde
flere knuder samt alternative veje mellem de forskellige knuder.
Der skelnes mellem alarmnettets
>ul
logiske
forbindelser mellem TSer, NCer og DCer, og PAXNETs
>ul
fysiske
forbindelser mellem netknuderne.
S}ledes kan en eller flere fysiske forbindelser godt v{re afbrudt
uden at dette beh|ver have nogen indflydelse p} de logiske forbindelser.
>ne25
Dette illustreres af f|lgende figur:
>sp 18
>fg Logiske og fysiske forbindelser
>a3 Nummerering i alarmnettet
Alarmsystemets netstruktur afspejles i nummereringen af abonnenter,
vagtcentraler og knuder, idet hver af disse f}r tildelt en 9-cifret
alarmnetadresse opbygget efter f|lgende system:
>ne10
A-BB-CC-DDDD
hvor
A @@@@@ angiver DC-nummer
>sp0
BB@@@@@ angiver NC-nummer under DC
>sp0
CC@@@@@ angiver TS-nummer under NC
>sp0
DDDD@@@ angiver abonnent-nummer under TS
(DDDD kaldes ogs} "mikroadresse")
Det skal understreges, at alarmnetadresser ikke har
noget med telefonnumre
at g|re.
>a2 Alarmsystemets funktioner
I dette afsnit vil systemets funktioner blive skitseret. De er alle
udf|rligt beskrevet i de efterf|lgende kapitler.
>ul
Oprettelse af vagtcentraler
styres fra DC. Relevante oplysninger indtastes via ekspeditionsterminalen
i DCs database og de videregives automatisk til de
ber|rte TSer. Se kapitel 3.
>ul
Oprettelse af abonnenter
foreg}r i et samspil mellem DC og vagtcentral. De relevante
abonnentoplysninger indtastes via ekspeditionsterminalen p} DC i
databasen. Se kapitel 2.
>ul
Nedl{ggelse af vagtcentraler
styres af DC-operat|ren. Se kapitel 3.
>ul
Nedl{ggelse af abonnenter
foreg}r i et samspil mellem DC-operat|ren og vagtcentralen. Se kapitel 2.
>ul
H}ndtering af alarmer
foreg}r autonomt i systemet, dvs. TS opsamler og videresender alarmer
til vagtcentral automatisk. H}ndtering af alarmer er beskrevet i
kapitel 4.
>ul
H}ndtering af styringer
initieres fra vagtcentralen og sendes automatisk gennem nettet til
den p}g{ldende AU. H}ndtering af styringer er beskrevet i kapitel 4.
>ul
Logning
af alle meddelelser (incl. alarmer og styringer) udf|res automatisk
af systemet. Alle log-meddelelser gemmes p} disc p} DC i et vist
tidsrum. Herefter arkiveres de p} magnetb}nd. Logning er beskrevet
i kapitel 5.
>ul
Overv}gning
er en af de vigtigste funktioner i alarmsystemet. Dels overv}ges
abonnentlinierne for brud og d}rlige transmissionsegenskaber. Ogs} selve
TSernes, NCernes og DCernes funktioner overv}ges.
Overv}gning er beskrevet i kapitel 6.
>ul
Vagtflytning
er en facilitet, der muligg|r at en vagtcentral for en periode kan
overflytte sine abonnenter til en anden vagtcentral (fx om natten,
under ferie etc.).
Vagtflytning er beskrevet i kapitel 7.
>ul
Fejlfinding
tilgodeses i alarmsystemet p} flere m}der. DC kan beordre ATen
til at udf|re en test (intern test). Vagtcentralen kan beordre
sit udstyr hos abonnenten (AU) til at udf|re en test (ekstern test).
Fejlfinding er beskrevet i kapitel 8.
>ul
Kryptering
af transmissionen p} abonnentlinien er en funktion, der kan tilbydes
abonnenter med stort behov for sabotagesikring (fx banker). Kryptering
er beskrevet i kapitel 9.
I kapitel 10 om systemet i
>ul
drift
beskrives funktioner som:
- taksering
- generelle meddelelser
- abonnentoplysninger
- opdatering af gr{nser
>a1 OPRETTELSE OG NEDL[GGELSE AF AT
I dette kapitel beskrives f|rst, hvordan abonnenter tilsluttes
alarmsystemet gennem en alarmterminal, og herefter hvordan
forbindelsen til systemet kan afbrydes.
>a2 Oprettelse af en AT
En oprettelse af en AT er en administrativ og installationsm{ssig procedure,
der foretages i samarbejde mellem bl.a ekspeditionskontoret, DC-operat|ren,
DC og prim{r vagtcentral.
Oprettelsen kan inddeles i punkter som p} nedenst}ende figur:
>ne 34
>sp 32
>fg Tilslutning af abonnent
1. Bestilling fra abonnent
2. Anmodning om oprettelse
3. Administrativ oprettelse
4. Logisk oprettelse af AT
5. Ordreseddel og -bekr{ftelse
6. Fysisk oprettelse af AT
7. Fysisk oprettelse af AU
8. Klarmelding fra mont|r
9. Klarmelding fra installationskontor
10. Test af transmission
11. DC-tilladelse til start poll
12. PVC-tilladelse til start poll
13. Start af poll
14. Poll er startet
Stiplede linier i denne type figurer betegner en systemm{ssig handling
fx afsendelse af en datapakke,
mens de fuldt optrukne linier indbefatter en personlig, skriftlig eller
telefonisk henvendelse.
>a3 Bestilling
En abonnent afgiver sin bestilling til den vagtcentral, der skal
fungere som prim{r vagtcentral (1). Denne videresender bestillingen
i form af en anmodning om oprettelse til ekspeditionskontoret p}
det distriktscenter, hvorunder abonnenten skal tilsluttes (2).
Hvis der |nskes kryptering, afleveres desuden en krypteringsordre
til operat|ren p} dette distriktscenter (se kapitel 9).
>a3 Administrativ oprettelse
P} ekspeditionskontoret foretages nu en administrativ oprettelse.
Der genereres alarmnetadresse m.m. til abonnenten og relevante
oplysninger indtastes p} ekspeditionsterminalen (3).
>a3 Logisk oprettelse
P} grundlag af denne indtastning foretages automatisk en logisk
oprettelse af den nye AT til forberedelse af den fysiske tilkobling
(4). Herunder sendes en meddelelse om oprettelse af AT til den TS,
hvor abonnenten skal tilsluttes, og der sendes opdateringsmeddelelser
til de DCer, hvor abonnentens vagtcentraler (prim{r og
alternative) er tilsluttet. Disse DCer videresender
oplysninger til TSerne, hvor vagtcentralerne er tilsluttet.
>a3 Ordreseddel og -bekr{ftelse
Der foretages ogs} automatisk udskrivning af en ordrebekr{ftelse
og en ordreseddel. Ordrebekr{ftelsen sendes til prim{r
vagtcentral (5), der kan kontrollere de indtastede oplysninger.
Ordresedlen g}r til installationskontoret p} distriktscentret (5)
og indeholder de oplysninger, der er n|dvendige for en fysisk
oprettelse.
>a3 Fysisk oprettelse
Herefter foretages den fysiske oprettelse af ATen og tilslutningen
til en TS fra installationskontoret (6). Ogs} alarmudstyret (AU) kan nu
opstilles af vagtcentralen og tilkobles ATen (7).
Efter oprettelse og tilslutning klarmelder mont|ren til installationskontoret
(8), der videregiver klarmeldingen til distriktscentret (9).
>a3 Test af transmission
Operat|ren p} det distriktscenter, hvor ATen er tilsluttet vil
herefter foretage en aftestning af transmissionen ud mod
abonnenten (10). Aftestningen indeholder en intern test og check
af AT-VC-forbindelse (se kapitel 8). N}r ATen fungerer korrekt, sendes
meddelelse til prim{r vagtcentral om, at DC giver tilladelse til at
starte poll (11).
>a3 Start af poll
N}r prim{r vagtcentral |nsker pollningen startet, sendes en tilladelse
hertil til ATens DC (12). N}r punkterne 11 og 12 begge er
udf|rt, sendes automatisk ordre om poll fra AT's DC til AT (13).
Pollning af AT startes, hvorefter der sendes kvittering til
DC (14).
>a2 Nedl{ggelse af en AT
Nedl{ggelse af en AT foretages fra operat|rkonsollen p} AT's
DC, men kr{ver accept fra AT's prim{re vagtcentral og foruds{tter,
at poll er stoppet (se 2.3).
En nedl{ggelse omfatter f|lgende punkter:
>ne 34
>sp33
>fg Nedl{ggelsesprocedure
1. Bestilling af nedl{ggelse
2. Anmodning om nedl{ggelse
3. Accept af nedl{ggelse
4. Ordreseddel og -bekr{ftelse
5. Logisk nedl{ggelse
6. Kvittering for nedl{ggelse
7. Fysisk nedl{ggelse
>a3 Anmodning om nedl{ggelse
P} bestilling (1) fra prim{r vagtcentral om nedl{ggelse af en af
dennes abonnenter sender operat|ren en datapakke indeholdende
anmodning om nedl{ggelse til PVC (2). PVC kan afsl} eller acceptere
(3). I tilf{lde af accept udskrives og sendes ordreseddel til
installationskontoret om nedl{ggelsen og ordrebekr{ftelse til PVC (4), og den
logiske nedl{ggelse startes automatisk (5).
>a3 Logisk nedl{ggelse
Den logiske nedl{ggelse best}r af en datapakke herom til AT's TS
og opdateringsmeddelelser til de DCer, hvor abonnentens
vagtcentraler er tilsluttet. Disse DCer videresender
opdateringsmeddelelserne til vagtcentralernes TSer.
>a3 Fysisk nedl{ggelse
AU fjernes af PVC, mens installationskontoret s|rger for fjernelse af
AT og dens tilslutning p} TS.
>a2 Nedlukning af en AT
Det er muligt at foretage en nedlukning af en AT midlertidigt
i forbindelse med betalingsrestance eller som opstart til en
permanent nedl{ggelse.
Nedlukningen best}r i at standse pollningen af den p}g{ldende
AT. Initiativet kommer fra PVC.
Proceduren udf|res herefter af operat|ren p} abonnentens distriktscenter,
og systemet kr{ver accept fra prim{r vagtcentral.
N}r operat|ren har indtastet en "stop poll"-kommando, sendes f|rst
en anmodning om stop poll til prim{r vagtcentral. PVC kvitterer
med accept eller afslag.
Ved afslag meddeles dette til operat|ren.
Ved accept sendes automatisk ordre om stop poll til den
p}g{ldende AT's TS. N}r poll er stoppet, kvitteres til
DC.
Fremgangsm}den ved en efterf|lgende start poll er fuldst{ndig
analog til den beskrevne procedure for stop poll.
>a1 OPRETTELSE OG NEDL[GGELSE AF VC
Dette kapitel omhandler vagtcentralers tilslutning til alarmsystemet
og afbrydelse af en s}dan tilslutning.
>a2 Oprettelse af en VC
Ligesom oprettelse af en AT er oprettelse af en vagtcentral en administrativ
og installationsm{ssig
procedure og startes p} ekspeditionskontoret p} det distriktscenter,
hvorunder vagtcentralen skal tilsluttes.
Oprettelsen best}r af f|lgende punkter:
>ne 33
>sp33
>fg Tilslutning af vagtcentral
1. Bestilling af oprettelse
2. Administrativ oprettelse
3. Logisk oprettelse
4. Ordreseddel og -bekr{ftelse
5. Fysisk oprettelse
6. Klarmelding fra mont|r
7. Klarmelding fra installationskontor
8. Test af transmission
9. Start af poll
10. Poll er startet
>a3 Administrativ oprettelse
Bestilling af oprettelse (1) afleveres til ekspeditionskontoret p}
det distriktscenter, hvor vagtcentralen skal tilsluttes.
Den administrative oprettelse foretages ved indtastning p}
ekspeditionsterminalen og generering af bl.a. alarmnetadresse (2). Specielt
indtastes hvilken af de to typer vagtcentraler (VC(AT) eller VC(IT)), oprettelsen omhandler.
Der kan ogs} angives, hvilke vagtcentraler der |nskes vagtflytteordning
med. Der vil s} automatisk blive sendt foresp|rgsler ud til disse
vagtcentraler, om de accepterer ordningen.
(For overskueligheden er dette ikke medtaget p} figuren).
En eventuel krypteringsordre afleveres til operat|ren (se kapitel 9).
>a3 Logisk oprettelse
Systemet foretager automatisk en logisk oprettelse af vagtcentralen
ved at sende en meddelelse ud til den TS, hvorunder vagtcentralen
tilsluttes (3).
>a3 Ordreseddel og -bekr{ftelse
I forbindelse hermed udskrives ordreseddel til installationskontoret
og ordrebekr{ftelse til vagtcentralen (4).
>a3 Fysisk oprettelse og tilslutning
Herefter kan installationskontoret
foretage den fysiske oprettelse af AT (hvis vagtcentralen er af type AT)
og s|rge for tilslutningen til TS (5). Herefter klarmeldes (6 + 7),
og aftestningen kan foretages fra operat|rkonsollen.
>a3 Start poll
N}r aftestningen er forl|bet tilfredsstillende, kan poll startes. Operat|ren
afgiver en start poll-kommando, der f}r systemet til at sende en start
poll-ordre til vagtcentralens TS (9). N}r poll er startet her,
kvitteres til distriktscentret (10).
>a2 Nedl{ggelse af en VC
Efter bestilling fra en vagtcentral kan nedl{ggelse af denne startes fra
operat|rkonsollen p} distriktscentret. Systemet kr{ver herunder accept
fra vagtcentralen selv.
En midlertidig nedlukning som den, der findes for ATer (beskrevet
i afsnit 2.3) kan ikke udf|res for vagtcentraler.
Ved den systemm{ssige nedl{ggelse foruds{ttes, at vagtcentralen ikke er prim{r
vagtcentral for nogen AT, og at vagt ikke er overf|rt til eller
fra andre vagtcentraler.
Nedl{ggelsen best}r af f|lgende punkter:
>ne 30
>sp 20
>fg Nedl{ggelsesprocedure
1. Bestilling af nedl{ggelse
2. Anmodning om nedl{ggelse
3. Accept af nedl{ggelse
4. Logisk nedl{ggelse
5. Ordreseddel og -bekr{ftelse
6. Fysisk nedl{ggelse
>a3 Logisk nedl{ggelse
Efter modtagelse af bestilling (1) indhenter systemet accept (2 + 3)
af nedl{ggelsen fra vagtcentralen.
Herefter afmeldes eventuelle ATer, som vagtcentralen er alternativ
vagtcentral for. I forbindelse hermed sendes ogs} besked til de
vagtcentraler, der er PVC for dise ATer. Der udsendes meddelelse
om nedl{ggelsen til de
vagtcentraler, der er vagtflytteordning med.
(For overskueligheden er dette ikke medtaget i figuren).
Selve nedl{ggelsesordren kan nu sendes til vagtcentralens TS.
Den logiske nedl{ggelse udf|res (4), hvorefter der kvitteres til
distriktscentret.
>a3 Fysisk nedl{ggelse
Installationskontoret vil modtage en ordreseddel, hvorefter tilslutningen
til TS kan fjernes, og hvis vagtcentralen er af type AT, fjernes
ogs} ATen.
>a1 H]NDTERING AF ALARMER OG STYRINGER
I dette kapitel beskrives alarmer, som sendes fra abonnenter til
vagtcentraler, og styringer fra vagtcentraler til abonnenter.
Overf|ringstiden for en alarm vil bl.a. p} grund af den h|je
transmissionshastighed i PAXNET normalt ikke overstige 10 sekunder.
>a2 Alarmer
De alarmer, der beskrives i dette afsnit omfatter to typer. Den
ene type best}r af de alarmer, der kan opst} hos en abonnent og som
registreres af abonnentens alarmudstyr. De kaldes
>ul
AU-alarmer.
Den anden
type omfatter fejl i selve alarmudstyret eller alarmterminalen. S}danne
fejl giver risiko for, at AU-alarmer ikke kan registreres eller videresendes,
hvorfor disse fejl m} resultere i en alarm. Denne type kaldes
>ul
statusalarmer.
Herudover findes andre typer alarmer, liniealarmer og servicealarmer.
Disse beskrives i kapitlet om overv}gning.
>a3 AU-alarmer
En alarm, der opst}r hos en abonnent og registreres af alarmudstyret
(AU), sendes via abonnentens alarmterminal (AT) til den terminalstation
(TS), hvor abonnenten er tilsluttet. Denne TS
afleverer alarmen til datanettet, der s|rger for, at
den n}r frem til vagtcentralens TS.
>a4 Bestemmelse af modtager
Alarmudstyret bestemmer modtageren af alarmen. Hvis der |nskes
en anden modtager end den, der blev benyttet ved sidste alarm, g|res
dette ved at sende et
>ul
adresseskift
med en
>ul
adressekode
til AT f|r
alarmen. Alarmen selv best}r af et vist antal bytes, der afleveres
til AT en ad gangen.
>ne 14
>sp 12
>fg En alarms vej
AT videresender f|rst en eventuel adressekode og dern{st alarmen
byte for byte til TS. I AT's kommunikation med TS sendes telegrammer,
hver best}ende af to bytes, idet den ene byte indeholder checkbits
og en operationskode, der fort{ller, hvordan den anden byte skal
fortolkes (fx adressekode eller alarmbyte ).
I TS bruges adressekoden til at bestemme dels modtageren af alarmen
(aktuel vagtcentral), dels antallet af bytes i alarmen. Vagtcentraler
af type AT kan dog kun modtage alarmer best}ende af een byte.
Modtageren bestemmes ud fra en tabel, som findes i TS for hver AT. Modtageren og antal
bytes benyttes, indtil AU igen sender en adressekode. Ved denne
bestemmelse af modtagervagtcentral tages i betragtning, om vagten
er flyttet til en anden vagtcentral.
>a4 Afsendelse af alarm
TS opsamler de tilsendte alarmbytes og sender alarmen som een datapakke
til den TS, hvor aktuel vagtcentral er tilsluttet.
Hvis aktuel vagtcentral ikke er identisk med prim{r vagtcentral (PVC)
eller den vagtcentral, som PVC m}tte have overf|rt sin vagt til,
sendes desuden en kopi af alarmen til PVC. Herudover sendes en kopi
af alarmen
>ul
til logning
p} det distriktscenter, hvor ATen er tilsluttet.
Skulle TS modtage et adresseskift under opsamling af alarmbytes til en
alarm, sendes de hidtil opsamlede bytes inden aktuel vagtcentral {ndres.
Hvis TS modtager en adressekode, der ikke st}r i den p}g{ldende ATs
tabel, inds{ttes PVC som aktuel vagtcentral, og PVC informeres om
fejlen.
>a4 Udsendelse til vagtcentral
N}r en alarm modtages p} vagtcentralens TS, s|rger denne TS for
videresendelse til vagtcentralen.
Hvis vagtcentralen er tilsluttet en anden DC end ATens DC,
sendes en kopi af alarmen fra vagtcentralens TS til logning p}
dennes DC. (Se kapitel 5 om logning).
Hvordan udpakning og videresendelse foreg}r, afh{nger af, om den
modtagende vagtcentral er af type AT eller IT.
For vagtcentraler af type AT foretages f|lgende: Afsenderens
alarmnetadresse, som er sendt sammen med alarmen, oms{ttes til en
adressekode for den p}g{ldende AT. Alarmnetadressen er en identifikation
af ATen i hele alarmsystemet, mens en adressekode er en v{rdi mellem
0 og 255, der for en vagtcentral af type AT entydigt bestemmer en af
dens ATer. En TS indeholder for hver VC(AT) en tabel over de
tilsluttede ATers alarmnetadresser og adressekoder.
Ligesom i kommunikationen mellem AT og TS foreg}r kommunikationen her
ved at sende telegrammer best}ende af to bytes, hvor den ene indeholder
checkbits og en operationskode, der fort{ller hvordan den anden
byte skal opfattes.
Alarmer sendes ud til vagtcentralen som 3 telegrammer:
>ne 4
- det f|rste fort{ller, at der kommer en AU-alarm,
- det n{ste telegram angiver AT-adressekoden,
- det sidste indeholder alarmbyten.
>ne 14
>sp 12
>fg En alarm til VC(AT)
Alarmer til vagtcentraler af type IT udsendes i een blok,
hvis l{ngde bestemmes af antallet af alarmbytes.
Blokken indeholder
>ne 4
- en operationskode, der angiver, at det er en AU-alarm,
- alarmnetadressen p} ATen
- de afsendte alarmbytes.
>ne 14
>sp 12
>fg En alarm til VC(IT)
N}r en alarm er afleveret fra TS til en vagtcentral, sendes en
meddelelse om denne aflevering til logning p} DC.
Der kan opst} en situation, hvor modtagervagtcentralen overf|rer
sin vagt, og dette endnu ikke er registreret i ATens TS i det |jeblik,
hvor en alarm opst}r. Alarmen vil i f|rste omgang blive sendt
til modtager-vagtcentralens TS og bliver herfra omdirigeret til
den vagtcentral, vagten er flyttet til.
Hvis en alarm af anden grund ikke kan afleveres af TS til
vagtcentralen, bliver den i stedet sendt til vagtcentralens DC.
Hvis datanettet ikke kan aflevere en alarm til vagtcentralens TS,
sendes denne alarm i stedet til PVC eller DC. Hvis alarmen oprindeligt
var sendt til en alternativ vagtcentral,
v{lges PVC. Hvis den
var adresseret til PVC, v{lges DC.
>a3 Statusalarmer
En anden form for alarm, statusalarm, opst}r hos abonnenten, n}r der
er fejl i alarmterminalen eller alarmudstyret.
F|lgende situationer giver anledning til en statusalarm:
- N}r str|mforsyningen skifter fra 220VAC til batteri
- N}r batterisp{nding n{rmer sig nedre funktionsgr{nse
- Ved restart efter fejl i ATen
- Ved fejl i kommunikationen over SERIF
- Ved AU-fejl
- Ved handshake-fejl i SERIF
- N}r der er g}et for lang tid mellem to
telegrammer fra TS til AT
I en del af ovenst}ende tilf{lde sendes ogs} en statusalarm, n}r
situationen oph|rer, fx n}r der skiftes til 220VAC.
En statusalarm bliver sendt b}de til PVC og DC.
Statusalarmer sendes p} samme m}de som beskrevet for
AU-alarmer i forrige afsnit med den forskel, at operationskoden,
der sendes ud til vagtcentralen her angiver statusalarm.
En vagtcentral af type AT kan ogs} give anledning til statusalarmer.
Disse sendes til egen DC.
>a2 Styringer
Styringer fra vagtcentraler kan inddeles i to typer:
- individuelle styringer og
- gruppestyringer
En individuel styring udf|res p} een
AT, mens en gruppestyring udf|res p} en hel gruppe ATer. Med
betegnelsen styring menes herefter en individuel styring.
>a3 Individuelle styringer
En styring fra en vagtcentral af type AT overf|res til TS i 3 telegrammer
indeholdende:
- operationskode for styring
- adressekode for abonnenten
- styrebyte
I TS oms{ttes adressekoden til en alarmnetadresse, der inds{ttes som modtager
af styringen. Styringen best}r af pr{cis een styrebyte.
>ne 14
>sp 12
>fg En styring fra VC(AT).
En vagtcentral af type IT sender styring til sin TS i een blok. Denne
indeholder:
>ne4
- operationskode for styring
- ATens alarmnetadresse
- antallet af styrebytes
- styrebytes
>ne 14
>sp 12
>fg Styring fra VC(IT).
For begge typer vagtcentraler g{lder, at styringen forsynes med
vagtcentralens alarmnetadresse som afsender og sendes til ATens TS.
Desuden logges styringen.
ATs TS kontrollerer, om styringen er
lovlig, dvs. om afsenderen har lov til at styre netop denne AT.
En AT kan styres af PVC og desuden af andre vagtcentraler, der
har speciel tilladelse til styring af den p}g{ldende AT. Herudover
kan den styres af en anden vagtcentral, n}r en af de ovenn{vnte
har overf|rt vagt til denne. Derimod kan DC ikke styre en AT.
Hvis styringen er lovlig, og AT befinder sig i en tilstand,
hvor den m} styres, sendes styrebytes ud til AT en ad gangen.
Hvis fx poll er stoppet, eller der er opst}et AU-fejl,
vil AT v{re i en tilstand, hvor der ikke m} styres.
>ne 13
>sp 11
>fg En styring til AT.
Gennemf|res styringen, sendes kvittering for dette til
vagtcentralens TS, ellers sendes kvittering for afvist styring.
Dette logges som s{dvanligt p} de involverede distriktscentre.
Fra vagtcentralens TS sendes kvitteringen for gennemf|rt styring
eller kvitteringen for afvist styring ud til vagtcentralen p}
samme format som en alarm. Dog angiver operationskoden, om
styringen er gennemf|rt eller afvist.
En styring, der ikke kan fremsendes af nettet, vil blive sendt
ud til vagtcentralen som en afvist styring.
>a3 Gruppestyring
En vagtcentral af type IT kan styre en gruppe af ATer gennem een
kommando.
Afsendelse af en gruppestyring foreg}r analogt til afsendelse af en
individuel styring fra en VC af type IT.
En s}dan gruppe ATer skal alle v{re tilsluttet samme TS, og gruppen
fastl{gges ved en TS-adresse og et interval af mikroadresser, der
angiver adresser p} ATer under denne TS.
Kommandoen for gruppestyring skal indeholde:
>ne6
- operationskode for gruppestyring
- TS-adresse
- nedre gr{nse for mikroadresse
- |vre gr{nse for mikroadresse
- antallet af styrebytes
- styrebytes
ATer inden for intervallet, som kan styres af den p}g{ldende vagtcentral,
vil alle modtage alle de sendte styrebytes.
Derimod vil den TS, som gruppestyringen sendes til, undlade at videresende
styrebytes til
ATer med adresser, som omfattes af det angivne interval, men ikke
m} styres af den p}g{ldende vagtcentral.
Der sendes ikke i s}danne tilf{lde kvittering for afvist styring.
>ne 14
>sp 12
>fg En gruppestyring.
>a1 LOGNING
Alle meddelelser, der sendes i alarmsystemet, vil blive logget dels
af dokumentationshensyn dels af statistikhensyn.
P} grund af de store v{rdier, der kan v{re p} spil, hvis en alarm
ikke n}r frem til vagtcentralen, kan det v{re af stor betydning
at kunne dokumentere, at alarmen
>ul
er
blevet modtaget p} vagtcentralen fra alarmsystemet.
Derfor bliver alarmer logget p} DC, b}de n}r de opst}r,
og n}r de er afleveret til vagtcentralen fra dennes terminalstation.
De n|jagtige tidspunkter for disse h{ndelser p}s{ttes logmeddelelserne.
Logningen foretages ogs} for at kunne lave statistikker
over systemets belastning og udnyttelse.
>a2 Opsamling af logmeddelelser
Logning foretages p} DCerne, der indeholder programmel til
opsamling af logmeddelelser p} en logfil. Med mellemrum foretages
dump fra logfilen over p} magnetb}nd.
Alle logmeddelelser bliver
sendt til n{rmeste DC. Meddelelser skal logges p} de
distriktscentre, hvorunder afsenderen og modtageren er tilsluttet.
Hvis afsender og modtager af en meddelelse er tilsluttet hver sin
DC, foretages logning s}ledes to steder.
>ne30
>sp28
>fg En meddelelse med tilh|rende logmeddelelser.
Den alarmnetknude, der afsender en meddelelse, skal lave en
kopi af meddelelsen og inds{tte tidspunkt heri til logning i den DC,
afsenderen er tilsluttet. Hvis den begivenhed, der ligger til grund
for en meddelelse, sker i en AT eller en VC, s|rger dennes TS for
logmeddelelsen. Hvis modtageren af en meddelelse er identisk med
afsenderens DC, skal afsenderen ikke lave kopi til logning, men
blot inds{tte tidspunkt i meddelelsen. S} vil den modtagende DC selv
s|rge for logning ud over den almindelige behandling af meddelelsen.
Hvis modtageren af en meddelelse er tilsluttet en anden DC end afsenderen,
skal den TS, som modtageren tilh|rer selv lave en kopi af meddelelsen
til logning i denne DC og inds{tte tidspunkt for modtagelsen af
meddelelsen.
I tilf{lde hvor en DC eller PAXNET-forbindelsen dertil er g}et
ned, tages der ingen kopier af meddelelser til logning for at undg}
"forstoppelse" i nettet.
En helt speciel meddelelse er typen "log af afleveret alarm", idet
denne meddelelse ikke er en kopi af en anden meddelelse, men
n{rmere en kvittering for en h{ndelse.
>a2 Udskrivning af logmeddelelser
P} anfordring fra DC-operat|ren kan n{rmere angivne dele af de
opsamlede logmeddelelser udskrives. Udskrivningen kan foretages
b}de fra logfilen p} disc og fra magnetb}nd.
Den |nskede delm{ngde af logmeddelelserne angives gennem parametre
til udskrivningskommandoen. Der kan v{lges en eller flere af
parametrene:
tid
adresse
afsender
modtager
operationskode
Hvis der fx angives et tidsrum og en adresse som parametre, udskrives
alle meddelelser, som har afsendelsestidspunkt i det p}g{ldende
tidsrum og har den p}g{ldende adresse som enten modtager eller afsender.
>a1 OVERV]GNING
Alarmsystemet overv}ger s}vel forbindelser som udstyr alle
steder i systemet.
Opst}r der en fejl et sted, meddeles den straks til de ber|rte
instanser.
Vi vil inddele beskrivelsen efter hvilken del af systemet, der
overv}ges:
- TSens overv}gning af AT
- ATs overv}gning af TS
- Knudeoverv}gning i
alarmnethierarkiet
>a2 TSens overv}gning af AT
AT overv}ges ved, at den med faste mellemrum kaldes fra TS, den
"polles". AT
>ul
skal
besvare et s}dant poll, enten med en OK-melding eller med en alarm,
hvis der er opst}et en s}dan.
Poll-frekvensen kan v{re afh{ngig af den enkelte AT-installation,
typisk vil den v{re omkring 2 sek.
Der skelnes mellem to typer af fejl p} forbindelsen til AT:
- liniealarm
- servicealarm
>a3 Liniealarm
En liniealarm optr{der, n}r der har v{ret et bestemt antal
transmissionsfejl
>ul
i tr{k.
Dette antal kan v{re afh{ngigt af den enkelte AT-installation,
typisk vil det v{re 3.
En liniealarm sendes af TS til b}de DC og PVC.
Liniealarmer optr{der, fx hvis telefonlinien afbrydes (m}ske ved
sabotage), eller hvis transmissionen forstyrres af st|j.
Liniealarmer skal derfor principielt tages lige s} alvorligt
som almindelige AU-alarmer.
N}r forbindelsen til AT er genoprettet, sendes automatisk
en afmelding til s}vel DC som PVC.
>a3 Servicealarm
Hvis transmissionskvaliteten falder under et givet niveau, skal der
afgives alarm. Dette sker efter f|lgende princip:
>ne 22
>sp 20
>fg Overv}gning af transmissionsfejl.
For hver korrekt transmission t{lles t{lleren et skridt ned og for
hver transmissionsfejl 1/a skridt op.
Der kan aldrig t{lles under 0.
Fx kan a v{re 0.05 = 5 % svarende
til en tolerance p} 5 transmissionsfejl pr. 100 transmissioner.
Dette giver 20 positive trin pr. fejl.
Ved c/a
(= servicegr{nse) afgives "servicealarm" til DC.
c kan fx v{re 5 svarende til servicealarm ved t{llertrin 100.
Dette skal give anledning til at DC-operat|ren tilkalder en
service-tekniker.
>a4 Stop-poll-alarm
Forts{tter transmissionskvaliteten med at v{re d}rlig, vil t{lleren
ogs} stige over d/a (= stop-poll-gr{nsen).
d kan fx v{re 9 svarende til stop-poll-alarm ved t{llertrin 180.
Herved afgives "stop-poll alarm" til DC, og forbindelsen m} nu regnes
for at v{re s} d}rlig, at der ikke l{ngere b|r polles, idet risikoen
for falske alarmer er for stor.
DC-operat|ren skal derfor stoppe pollningen p} normal vis (dvs. i
samarbejde med PVC). Pollning stoppes alts}
>ul
ikke
automatisk af TS ved en stop-poll-alarm.
Efter at t{lleren har passeret stop-poll-gr{nsen i opadg}ende
retning t{lles den ikke yderligere op.
N}r linien bliver udbedret og pollningen genoptages, vil t{lleren
automatisk falde tilbage mod 0.
Idet den passerer stop-poll-gr{nsen og servicegr{nsen for
nedadg}ende afmeldes henholdsvis stop-poll-alarm og servicealarm.
>a2 ATs overv}gning af TS
Det er vigtigt for alarmudstyret at vide, om der er forbindelse
til vagtcentralen, idet det i modsat fald eventuelt skal afgive
lokal alarm og m}ske starte lokale afv{rgeforanstaltninger -
fx t{nding af lys eller alarmklokke.
Derfor indeholder AT en timer, som vil give AU besked, s}fremt
AT ikke er blevet pollet af TS inden for et givet tidsrum (typisk
15 sek.).
>a2 Alarmnetudfald
Knuderne i alarmnettets hierarki udf|rer en overv}gning af den
underliggende del af hierarkiet, idet de med faste mellemrum sender
en s}kaldt
>ul
knudetest
til alle alarmnetknuder p} det underliggende niveau.
DCs netknude sender s}ledes med faste mellemrum knudetest til alle
NCer under den p}g{ldende DC.
Endvidere sendes knudetest til de andre DCer.
Der skal kvitteres for en s}dan knudetest. Udebliver en kvittering
er DC herved i stand til at opdage, at forbindelsen til den del af
hierarkiet, som den udeblevne DC eller NC repr{senterer, er faldet bort.
Tilsvarende sender en NC knudetest til sine underliggende TSer.
Knuderne overv}ger ogs} alarmnet-forbindelserne opadtil, idet de holder
|je med, om de modtager en knudetest med passende mellemrum.
G|r de ikke det, vil de underrette den underliggende del af nettet
om alarmnet-udfaldet.
Det skal understreges, at det er de
>ul
logiske
forbindelser, der overv}ges ved denne knudetest og ikke de
fysiske.
Den direkte transmissionslinie mellem fx en DC og en af dens NCer kan
alts} godt v{re afbrudt uden at dette n|dvendigvis f|rer til,
at den p}g{ldende gren af alarmnettet betragtes som faldet bort.
Dette vil fremg} af f|lgende eksempel:
>ex Liniebrud
Lad os se p} en DC med to NCer:
>ne 16
>sp 10
>fg Normal vej for knudetest
Der er en alternativ vej direkte mellem de to NCer.
En knudetest vil under normale omst{ndigheder af PAXNET blive
sendt den direkte vej fra DC til fx NC1.
Opst}r der et brud p} linien mellem DC og NC1 vil knudetesten
nu blive dirigeret fra DC via NC2 frem til NC1:
>ne 16
>sp10
>fg Vej for knudetest ved brud
og kvitteringen vil g} den modsatte vej. Dvs. DCs overv}gning
af NC1 vil ikke reagere p} det p}g{ldende liniebrud, hvilket
ogs} er korrekt, idet der stadig er forbindelse til den del
af alarmhierarkiet, som NC1 repr{senterer.
>ul
Liniebruddet
opdages p} PAXNETs netkontrolcenter, hvorfra der vil blive taget
initiativ til at f} det udbedret.
>a3 Broadcast
Opdages et brud i alarmnethierarkiet ved denne knudetest, vil den
"opdagende" knude underrette s}vel den overliggende knude, som
alle de af dens underliggende knuder, den har forbindelse til.
Dette sker i form af en
>ul
broadcast-meddelelse.
N}r en knude f}r denne meddelelse
>ul
oppefra
i nettet, sendes den videre til alle underliggende knuder.
Kommer den
>ul
nedefra
sendes den til s}vel den overliggende knude som til alle
underliggende knuder (undtagen den, som den kom fra).
Knuden p} DC sender desuden meddelelsen videre til de andre DCer.
TSerne under bruddet - alts} i den del, der er faldet v{k - s|rger
for at underrette de underliggende VCer om fejlen, og holder op
med at POLLe de ATer, hvis PVC ligger p} den anden side af
bruddet.
Endelig vil et alarmnetudfald blive udskrevet p} DCs hovedkonsol
med angivelse af den fejlramte str{kning.
N}r fejlen er udbedret, rundsendes ("broadcastes") meddelelse herom
p} samme m}de som ved fejlens opst}en (meddelelsen udbredes til
alle "som ringe i vandet").
>a1 VAGTFLYTNING
Det er muligt for en vagtcentral at overf|re sin vagt til en anden
vagtcentral fx om natten eller i week-enden. N}r vagtcentralen
senere |nsker at genoptage vagten, foretages en vagtreturnering.
En foruds{tning for en vagtoverf|rsel er, at der er etableret
vagtflytteordning mellem de involverede vagtcentraler (se kap. 3).
Herudover skal en vagtoverf|rsel accepteres af den modtagende
vagtcentral i hvert enkelt tilf{lde, f|r flytningen kan foretages.
Ved en vagtflytning overf|res
>ul
alle
vagtcentralens abonnenter, b}de de, der har den p}g{ldende vagtcentral
som prim{r vagtcentral, og de, der har vagtcentralen som alternativ
vagtcentral. Hvis vagtcentralen p} overf|rselstidspunktet har f}et
overf|rt vagt fra andre vagtcentraler, flyttes ogs} disse vagtcentralers
abonnenter.
En overf|rsel fra en vagtcentral kan kun startes p} initiativ af
vagtcentralen selv eller DC-operat|ren i samme distrikt. I nogle
tilf{lde af liniebrud, hvor der mistes forbindelse fra en
vagtcentral til en del af dennes abonnenter, vil en vagtflytning
initieret af DC-operat|ren kunne give netop denne del af abonnenterne
kontakt med en anden vagtcentral.
En vagtcentral af type IT kan ikke overf|re vagt til en vagtcentral
af type AT. Denne restriktion skyldes dels VC(AT)ens begr{nsning p}
abonnentantal, dels at en VC(AT) benytter koder for
alarmnetadresser.
For at anskueligg|re proceduren vises
i dette kapitel ved hj{lp af tegninger et gennemg}ende eksempel p} vagtflytning.
VC1 er en vagtcentral, der |nsker at overf|re sin vagt til VC2. VC1
har tidligere f}et overf|rt vagt fra VC3. Abonnenterne AT1.1 og AT1.2
er tilsluttet VC1, AT3.1 er tilsluttet VC3.
I disse AT-betegnelser refererer tallet f|r "." til ATens
vagtcentral, mens tallet efter "." er et l|benummer inden for
denne vagtcentral.
Senere i kapitlet vises en vagtreturnering til VC1.
>a2 Vagtflytning initieret af vagtcentralen
N}r en vagtcentral |nsker at overf|re sin vagt til en anden,
f|lges den nedenfor beskrevne procedure:
>ne 20
>sp 16
>fg Start af vagtflytning fra VC1 til VC2
1. Anmodning om vagtflytning
2. Accept eller afslag
Vagtcentralen starter med at afgive en anmodning (1) til sin TS om
vagtoverf|rsel med angivelse af hvilken vagtcentral, vagten |nskes
overf|rt til.
Hvis der eksisterer vagtflytteordning, sendes anmodningen (1)
fra vagtcentralens TS til modtagervagtcentralen, der kan
acceptere eller afsl} den aktuelle vagtflytning (2). I tilf{lde
af afslag meddeles dette vagtcentralen, og proceduren stoppes.
Accepteres vagtflytningen kan den egentlige overf|rsel nu
startes. Denne foretages i to afdelinger: f|rst en
>ul
flytning
>ul
af vagtcentralens egne abonnenter,
herefter en
>ul
videreflytning
af de eventuelle andre vagtcentralers
abonnenter, der for tiden er overf|rt til denne vagtcentral.
>a3 Flytning af egne abonnenter
Flytning af vagtcentralens egne abonnenter foreg}r s}ledes:
>ne 20
>sp 16
>fg Flytning af VC1's egne abonnenter
3. Meddelelse om flytning
4. Kvittering for flytning
Der sendes en meddelelse om vagtflytning (3) til den
modtagende vagtcentrals TS og til de TSer, hvor abonnenterne er
tilsluttet. P} grundlag af disse meddelelser foretages de n|dvendige
tabelopdateringer. N}r
disse er udf|rt, sendes en kvittering (4) tilbage til
vagtcentralens TS.
>ne 28
>a3 Videreflytning af |vrige abonnenter
Nu foretages en flytning af abonnenterne p} de vagtcentraler,
der har udf|rt vagtflytning til denne vagtcentral.
>ne 24
>sp 16
>fg Videreflytning af VC3's abonnenter
5. Meddelelse om videreflytning
6. Meddelelse om flytning til modtager-VC og ATers
TSer
7. Kvittering for flytning
8. Kvittering for videreflytning
Der sendes en meddelelse om videreflytning (5) for hver af disse
vagtcentraler. Denne meddelelse sendes til de p}g{ldende vagtcentralers
TSer og indeholder bl.a. adressen p} den modtagende vagtcentral og
adressen p} den vagtcentral, hvis abonnenter videreflyttes.
TSerne foretager p} dette grundlag automatisk en flytning (6+7) af disse vagtcentralers
abonnenter til den modtagende vagtcentral. Hver af disse flytninger
svarer til flytningen (3+4) beskrevet i foreg}ende afsnit.
Efter udf|relse af en videreflytning sendes en kvittering (8) herfor til
TSen, hvor den vagtcentral, der overf|rer vagt, er tilsluttet.
N}r denne TS har modtaget kvitteringer for alle beordrede videreflytninger
og kvitteringer for alle simple flytninger (se afsnit 7.1.1), er
vagtflytningen udf|rt.
>a2 Vagtflytning initieret fra DC
En vagtflytning startet af DC-operat|ren foreg}r analogt til en
vagtflytning startet af vagtcentralen selv, men proceduren styres af
DC i stedet for af vagtcentralens TS. Dette betyder bl.a.,
at kvitteringerne opsamles p} DC. Denne form
for vagtflytning foreg}r i tilf{lde af alarmnetudfald ud mod vagtcentralen,
s}ledes at en del af vagtcentralens abonnenter er uden forbindelse med
deres vagtcentral.
DC-operat|ren anmoder om en vagtflytning og angiver de to involverede
vagtcentraler, dvs. den afsendende og den modtagende. Hvis der eksisterer
vagtflytteordning mellem de to vagtcentraler, sendes anmodningen til
modtagervagtcentralen. Denne kan acceptere eller afsl} vagtflytningen.
Hvis der accepteres, udf|res vagtflytningen som en flytning af
vagtcentralens egne abonnenter efterfulgt af eventuelle videreflytninger
af andre vagtcentralers abonnenter som i afsnit 7.1, blot med den
forskel, at kvitteringer sendes til DC i stedet for til
vagtcentralen.
Det m} forventes, at en del af meddelelserne ikke n}r frem p} grund af
alarmnetudfald. Disse meddelelser returneres til DC.
Vagtflytningen er udf|rt, n}r DC har modtaget kvittering
for eller returnering af alle udsendte meddelelser.
>a2 Vagtreturnering
Ligesom vagtflytning kan vagtreturnering initieres af vagtcentralen
selv og DC-operat|ren p} vagtcentralens DC.
I tilf{lde hvor DC-operat|ren har udf|rt vagtflytning p} grund af
brud p} nettet, skal samme DC automatisk tage initiativ til en
vagtreturnering, s} snart nettet er genoprettet.
>a3 Returnering initieret af vagtcentralen
"Ejer-vagtcentralen" dvs. den vagtcentral, hvor abonnenterne er tilmeldt,
men midlertidigt overflyttet fra, kan kr{ve en returnering.
>ne 20
>sp 16
>fg Start p} returnering
9. Krav om returnering
10. Kvittering
Vagtcentralen kr{ver (9) returneringen af sin egen TS.
Kravet (9) sendes af TS automatisk til den aktuelle vagtcentral, dvs. den vagtcentral,
der har vagten over abonnenterne. Denne vagtcentral er ikke n|dvendigvis
identisk med den vagtcentral, som ejer-vagtcentralen selv flyttede
sin vagt til, idet der kan v{re sket en videreflytning af abonnenterne.
Men adressen p} den aktuelle vagtcentral opbevares i ejervagtcentralens TS.
Den aktuelle vagtcentral kvitterer (10) for meddelelsen til ejer-vagtcentralen,
og begge vagtcentralers TS foretager de n|dvendige tabel{ndringer.
Herefter udf|res returneringen automatisk af ejer-vagtcentralens TS.
Selve returneringen foreg}r i to afdelinger, f|rst en returnering af
ejer-vagtcentralens egne abonnenter og senere en returnering af
abonnenterne fra de vagtcentraler, der havde overf|rt vagt til denne
vagtcentral, da denne vagtcentral foretog flytning.
Dog udf|res den ikke for de vagtcentraler,
der i mellemtiden selv har returneret deres vagt.
>ne 20
>sp 16
>fg Returnering af egne abonnenter
11. Meddelelse om returnering
12. Kvittering for returnering
Returnering af egne abonnenter best}r af en meddelelse om returnering (11)
til hver af de TSer, hvor vagtcentralens abonnenter er tilsluttet.
Disse TSer kvitterer (12) efter at have foretaget de n|dvendige tabel{ndringer.
>ne 22
>sp 16
>fg Returnering af andre vagtcentralers abonnenter
13. Meddelelse om videreflytning
14. Meddelelse om flytning
15. Kvittering for flytning
16. Kvittering for videreflytning
Anden afdeling af returneringen foretages som en videreflytning
(afsnit 7.1.2) for hver af de ovenn{vnte vagtcentraler (13, 14, 15 og 16).
Dog udf|res den ikke for de vagtcentraler, der i mellemtiden selv har
returneret deres vagt.
>a3 Returnering initieret fra DC
Hvis en DC-operat|r p} grund af brud p} alarmnettet har foranstaltet vagtflytning
for en vagtcentral, skal samme DC efter genoprettelse
af nettet starte en vagtreturnering.
Det er muligt, at vagtcentralen selv har foretaget en vagtflytning
til en anden vagtcentral, mens der var brud p} nettet.
Et brud p} nettet kan bevirke, at ikke alle abonnenter har forbindelse
til vagtcentralen.
Denne vagtflytning har i s} fald kun omfattet de abonnenter, som p} det
tidspunkt havde forbindelse til vagtcentralen, og skal nu
udvides til at omfatte alle vagtcentralens abonnenter. I s}danne
tilf{lde bliver en returnering, der er startet fra DC,
derfor automatisk efterfulgt af en vagtflytning.
>ne 24
>ex Returnering fra DC
>sp16
>fg Situation med alarmnetudfald
Ovenst}ende figur viser et eksempel p} alarmnetudfald, hvor
VC4 ikke har forbindelse til sin abonnent AT4.1.
Det foruds{ttes, at DC har overf|rt VC4s vagt til VC6,
hvorved AT4.1 har f}et forbindelse til en vagtcentral.
Denne vagtflytning har ikke ber|rt VC4s abonnent AT4.2,
da DC ikke har forbindelse hertil.
Det bem{rkes, at VC4 selv har forbindelse til AT4.2.
Mens der er alarmnetudfald udf|rer VC4 en vagtflytning til VC5.
Denne vagtflytning omfatter kun AT4.2 p} grund af den
manglende forbindelse til AT4.1.
N}r nettet er genoprettet skal DC automatisk s|rge for, at den vagtflytning,
som VC4 har udf|rt, kommer til at g{lde for begge VC4s abonnenter.
Dette udf|res rent teknisk ved f|rst at foretage en
returnering af VC4s abonnenter for at genskabe konsistensen
i alarmnettet. Umiddelbart derefter foretages en vagtflytning
til VC5, der s} omfatter b}de AT4.1 og AT4.2.
>a4 Fremgangsm}de ved returnering
Returnering startes ved en ordre om returnering fra DC
til vagtcentralens TS. Hvis vagtcentralen ikke har foretaget
vagtflytning, gives besked ud til vagtcentralen om den forest}ende
returnering. (Vagtcentralens TS indeholder oplysning om den
aktuelle vagtcentral.)
Vagtcentralens TS foretager herefter returnering som beskrevet
i afsnit 7.3.1 med den forskel, at vagtcentralen ikke m}
inds{ttes som aktuel vagtcentral, hvis vagten reelt er overf|rt til en
anden vagtcentral.
N}r vagtreturneringen er udf|rt, forts{ttes med en vagtflytning,
hvis vagten i forvejen var overf|rt for de abonnenter,
der havde forbindelse til vagtcentralen. Denne vagtflytning vil s} resultere i,
at vagten er overf|rt for alle abonnenter.
>a1 FEJLFINDING
Dette kapitel beskriver hvilke midler, der st}r til r}dighed for at
finde de fejl, der opst}r under drift af alarmsystemet.
Vi vil opdele beskrivelsen efter hvilken type fejl, det drejer sig
om:
- fejl i datanettet
- fejl mellem TS og abonnent
>a2 Fejl i datanettet
Disse fejl opdages af PAXNETs netkontrolcenter, der vil tage
initiativ til at f} fejlen udbedret.
S}fremt fejlen indeb{rer, at dele af alarmnettets hierarki falder
v{k, vil alarmsystemet ogs} opdage fejlen (se kapitel 6), men
fejlretningsinitiativet kommer ikke herfra.
>a3 Check af AT-VC forbindelse
S}fremt DC-operat|ren |nsker at kontrollere, at der er forbindelse
mellem en ATs TS og den tilsvarende VCs TS, kan han f} denne forbindelse
checket ved hj{lp af en "dummy-alarm".
Dette sker ved, at DC beordrer ATens TS til at generere en dummy-alarm til
VCens TS. VCens TS skal kvittere for dummy-alarmen, og n}r kvitteringen
kommer retur til ATens TS, meddeler denne det til DC.
Princippet er skitseret i f|lgende figur:
>ne22
>sp10
>fg dummy alarm
1. operat|r anmodning
2. kommando DC -> ATs TS
3. dummy alarm ATs TS -> VCs TS
4. kvittering VCs TS -> ATs TS
5. kvittering ATs TS -> DC
6. udskrift p} operat|r konsol
>a2 Fejl mellem TS og abonnent
Denne type fejl opdages ved, at der kommer en af f|lgende typer
alarmer fra abonnentens TS:
- statusalarm
- liniealarm
- servicealarm
Abonnenten kan i denne sammenh{ng ogs} v{re en VC(AT).
>a3 Statusalarmer
Er der tale om en
>ul
statusalarm,
vil denne indeholde en beskrivelse af fejlen (fx afbrydelse
af 220VAC, AU-fejl, SERIF-fejl osv).
Er der tale om
>ul
AU-fejl
er fejlen med det samme lokaliseret til AU.
220VAC svigt og n|dstr|msbatteriets afladetilstand er ogs} konstateret umiddelbart.
Er der tale om fejl i forbindelsen til AU (SERIF-fejl, handshakefejl)
er det n|dvendigt at kunne lokalisere fejlen til enten AT eller AU.
Til det form}l findes to fjerntests:
- intern test
- ekstern test
>a4 Intern test
Denne test kan udf|res fra operat|rkonsollen p} DC.
Den er begr{nset til at fjernstyre AT til at foretage en
selvtest samt meddele resultatet af denne.
Der findes to typer af intern test:
- intern test 1
- intern test 2
som bruges til at teste st|rre eller mindre dele af AT.
>ul
Intern test 1
bruges til at teste ATens grundenhed ud til SERIF.
>ul
Intern test 2
er kun relevant, s}fremt AT indeholder et parallelmodul.
I s} fald testes funktioner i grundenheden samt i parallelmodulet.
Begge disse tests kan
>ul
kun
udf|res fra DC.
>a4 Ekstern test
Form}let med denne test er at give vagtcentralen mulighed for at
afteste sit alarmudstyr (AU).
Vagtcentralen kan beordre sit udstyr til at gennemf|re mange
forskellige slags test, idet der er reserveret en byte i ekstern
test meddelelsen fra vagtcentralen til AUen.
Ligeledes har AU mulighed for at meddele et differentieret
resultat af testen, idet der ogs} i svaret p} ekstern test fra
AU til vagtcentral er afsat en hel byte til resultat.
Det skal understreges, at det er helt op til vagtcentralen at
definere betydningen af s}vel ekstern test som resultatet af denne.
En ekstern test kan
>ul
kun
afsendes fra abonnentens prim{re vagtcentral
(eller den vagtcentral som PVC evt. har overf|rt sin vagt til).
>a3 Liniealarm og servicealarm
Er fejlen opdaget ved, at der er afgivet linie- eller servicealarm,
er der flere muligheder for dens lokalisering:
- fejl i TS
- fejl p} linien mellem TS og AT
- fejl i AT
Til brug ved fejlfindingen findes et testudstyr, ATTS-tester.
>a4 ATTS-tester
ATTS er et b{rbart testudstyr for fejlfinding i kommunikationsvejen
mellem alarmterminaler og terminalstationer.
Funktionsm{ssigt har ATTS tre hovedopgaver:
- simulere alarmterminal og meddele
resultat til fejlretter
- simulere terminalstation og meddele
resultat til fejlretter
- m}le modtagne 8KHz niveau og vise
dette for fejlretter
ATTS har et betjeningspanel
for kommunikation
mellem fejlretter og udstyr.
Til udstyret h|rer fortrykte fejlrapporteringsformularer og en
brugervejledning, der leder fejlretteren gennem korrekt
fejlfindings- og fejlretningsprocedure.
Fejlfinding m} f|rst iv{rks{ttes, n}r fejl er konstateret.
Ved fejl forst}s her fejl, som INTERN TEST (1 og 2) ikke har
fastlagt til AU. Dvs. hvis en vagtcentral melder, at noget
er galt med forbindelsen til et alarmudstyr (AU), vil DC
pr|ve at foretage INTERN TEST. G}r dette godt m} fejlen
skyldes AU - alts} abonnentens eget udstyr.
ATTS kan tilsluttes p} fire m}der:
>ne 20
>sp 18
>fg Tilslutning af ATTS.
Proceduren for fejlfinding indeholder fire trin svarende til de
fire tilslutninger:
>in8
>ti-8
Trin 1:@ATTS simulerer AT mod TS med linien frakoblet
(tilslutningspunkt 1).
>ti-8
Trin 2:@ATTS simulerer TS mod AT med TS frakoblet
(tilslutningspunkt 1).
>ti-8
Trin 3:@ATTS simulerer AT mod TS med AT frakoblet
(tilslutningspunkt 2).
>ti-8
Trin 4:@ATTS simulerer TS mod AT med linien frakoblet
(tilslutningspunkt 2).
>in-8
>a4 Servicepoll
For at kunne benytte ATTS er det n|dvendigt at TS poller AT, dog
uden at sende eventuel status og alarmer videre til vagtcentral
eller DC.
Denne tilstand kaldes servicepoll.
Start af servicepoll af en AT kan kun foretages fra ATens
DC og kr{ver tilladelse fra ATens prim{re vagtcentral, s}fremt
ATen i forvejen polles.
Der kr{ves alts} ikke tilladelse, hvis pollningen i forvejen
er stoppet eller hvis ATen er under oprettelse.
>a1 KRYPTERING
S}fremt abonnenten |nsker en s{rlig beskyttelse af transmissionen, vil det v{re
af betydning, at uvedkommende ikke kan g} ind p} transmissionslinien
mellem AT og TS og fx simulere over for TS, at AT "har det godt", mens
der foretages et indbrud.
>ne 22
>sp 20
>fg Aflytning af transmission.
Det er derfor muligt at
>ul
kryptere
den information, der sendes mellem AT og TS. Ogs} transmissionen til
en vagtcentral kan krypteres.
At kryptere vil sige at g|re en meddelelse "uforst}elig" p} en s}dan
m}de, at kun modtageren - ved brug af en speciel kode - kan dechifrere den.
>a2 Krypteringsmetode
Kryptering p} en transmissionslinie foreg}r ved, at afsender
og modtager begge er i besiddelse af en "n|gle" (dvs. en kode). Afsenderen
transformerer informationen ved hj{lp af n|glen p} en s}dan m}de, at det
kun er muligt at "dekryptere" den ved anvendelse af den samme n|gle.
Krypteringen foreg}r alts} s}ledes:
>ne 16
>sp 14
>fg Krypteringsmetode
Selve algoritmen, der anvendes til kryptering er "Data Encryption
Standard" (DES), som er anbefalet af US National Bureau of Standards.
DES anvender en 64-bits n|gle til kryptering og dekryptering.
Denne n|gle opbevares b}de i DCs database og i TS. Desuden findes den
lagret i en Read-Only-Memory ("br{ndt ind i en ROM"), der er placeret i AT.
>ne 25
>sp 24
>fg Krypteringsn|gler
Det er af betydning for sikkerheden i systemet, at ingen
>ul
personer
kan afl{se krypteringsn|glen for en given linie.
(N|glen er alts} "uber|rt af menneskeh{nder").
Dette sikres ved at systemet (dvs. DC) automatisk genererer en
(tilf{ldig) n|gle, hver gang der skal installeres en AT med kryptering.
Denne n|gle transmitteres automatisk til den p}g{ldende ATs TS.
Desuden br{ndes den (stadig automatisk) ind i en ROM, som af
>ul
vagtcentralens
personale transporteres til abonnentens AT.
>a2 Administrative procedurer
I det f|lgende beskrives de administrative og installationsm{ssige procedurer, der skal f|lges
ved henholdsvis oprettelse, {ndring og sletning af krypteringsn|gler.
Det er kun en abonnents prim{re vagtcentral, der kan oprette, {ndre
og slette den p}g{ldende kryptering, s} n}r der i det f|lgende
tales om "vagtcentral" menes der "abonnentens prim{re vagtcentral".
>a3 Nyoprettelse
Ved nyoprettelse af en AT med kryptering bestilles krypteringen
samtidig med AT.
Proceduren er identisk med proceduren for nyoprettelse af en AT, bortset
fra indbr{nding af krypteringsn|glen i ROMen, samt ROMens transport
til installationsstedet.
>a4 F|lgeseddel til ROM
Samtidig med at der udskrives ordreseddel til installationskontoret,
udskrives en f|lgeseddel til krypterings-ROMen. Denne f|lgeseddel
indeholder bl.a. et l|benummer, idet det er n|dvendigt at kunne
identificere ROMen entydigt med en l{sbar tekst (som naturligvis
>ul
ikke
m} v{re selve krypteringsn|glen).
Disse l|benumre genereres fortl|bende p} hvert distriktscenter og
i ROMens identifikation indg}r b}de distriktcentrets nummer og
l|benummer.
F|lgesedlen, der indeholder denne identifikation samt
installationsstedets og vagtcentralens navn og adresse, opbevares af
DCs operat|r indtil ROMen skal br{ndes.
>a4 Br{nding af ROM
En person fra vagtfirmaet skal overv{re indbr{nding af krypteringsn|glen
i ROMen samt transportere denne til installationsstedet.
N}r personen fra vagtfirmaet ankommer til distriktscentret s{tter
DC-operat|ren en ROM i ROM-br{nderen, hvorefter han indtaster en
ordre om br{nding med det p}g{ldende l|benummer. ROMen m{rkes med
l|benummeret og udleveres sammen med f|lgesedlen til personen fra vagtfirmaet,
der transporterer den til installationsstedet.
Her monteres den i AT af en mont|r (fra telefonselskabet).
>a3 [ndring af N|gle
Det er muligt at f} {ndret en krypteringsn|gle i en allerede
installeret AT, og det b|r ogs} anbefales at f} dette gjort
med j{vne mellemrum.
[ndringsproceduren er beskrevet i f|lgende 18 punkter:
>ne 50
>sp 24
>fg Procedure for {ndring af n|gle
1. Bestilling af kryptering
2. Indtastning af bestilling
3. Generering af ny n|gle
4. F|lgeseddel til ROM
5. Ordreseddel til installationskontor
6. Ordrebekr{ftelse til vagtfirma
7. Ordre om br{nding af ROM
8. Br{nding af ROM
9. Anmodning om stop poll
10. Accept af stop poll
11. Ordre om stop poll
12. ROM monteres i AT
13. Load af n|gle til TS
14. Klarmelding til DC
15. Test af transmission
16. DC-tilladelse til start poll
17. PVC-tilladelse til start poll
18. Ordre om start poll
>a4 Bestilling
Dette foreg}r ved at vagtfirmaet ringer eller skriver til distriktscentrets
ekspeditionskontor og anmoder om at f} {ndret krypteringsn|glen
for den p}g{ldende abonnent (1).
Bestillingen indtastes p} ekspeditionsterminalen (2), hvilket
giver anledning til at der genereres en ny krypteringsn|gle,
der lagres i databasen (3).
Herefter udskrives automatisk en f|lgeseddel til ROMen (4) (se
afsnit 9.2.1.1) samt en ordreseddel til installationskontoret (5).
Endelig udskrives en ordrebekr{ftelse til vagtfirmaet (6).
>a4 Br{nding af ROM
Selve br{ndingen foreg}r som beskrevet i afsnit 9.2.1.2.
>a4 Udskiftning af ROM
Selve udskiftningen til den nye krypteringsn|gle finder sted,
n}r s}vel personen fra vagtfirmaet med den nye ROM som telefonselskabets
mont|r er kommet til stede p} installationsstedet.
F|rst skal pollningen imidlertid stoppes.
Dette foreg}r som beskrevet i afsnit 2.3. (9 + 10 + 11).
N}r pollningen er stoppet udskiftes ROMen (12) og samtidig
loades den nye n|gle fra DCs database til TS (13).
Herefter testes transmissionen og pollningen startes som beskrevet
i afsnit 2.1.7. (14..18).
>a3 Sletning af kryptering
\nsker et vagtfirma at fjerne en abonnents kryptering, er den
administrative procedure analog med modsat fortegn med den, der
blev beskrevet i foreg}ende afsnit om {ndring, n}r bortses fra de
dele, der vedr|rer ROMen.
>a1 DRIFT
I dette kapitel beskrives de funktioner, der vedr|rer alarmsystemets
drift. Det drejer sig om:
- takseringsmuligheder
- generelle meddelelser
- abonnentoplysninger
- opdatering af alarmgr{nser
>a2 Takseringsmuligheder
Der findes en pakket{ller for hver AT og VC i den tilknyttede TS. Den
benyttes til registrering af antal afsendte data-pakker. Hver gang
der afsendes en data-pakke fra en AT eller VC, vil dennes pakket{ller
blive talt op med 1.
Fra DC foretages automatisk en afl{sning af pakket{llere p} alle
underliggende ATer og VCer een gang i d|gnet.
Sidst afl{ste pakket{ller gemmes p} DC og benyttes til at
udregne antallet af afsendte meddelelser siden sidste afl{sning.
Disse antal akkumuleres i DCs database.
Taksering foretages ud fra den akkumulerede pakket{ller.
>a2 Generelle meddelelser
En generel meddelelse er en tekststreng, som kan sendes fra een
operat|r til en anden. En operat|r er i denne forbindelse en DC-operat|r
eller en VC(IT)-operat|r.
Generelle meddelelser kan bruges til vilk}rlige meddelelser operat|rerne
imellem.
VC(AT)er kan hverken sende eller modtage generelle meddelelser.
>a2 Abonnentoplysninger
Hvis prim{r vagtcentral er af type VC(IT) kan den f} tilsendt
abonnentoplysninger direkte via alarmnettet fra DCs database.
Det drejer sig om:
navn
adresse
AT-type
+/- kryptering
oplysninger om alternative vagtcentraler
>a2 Opdatering af alarmgr{nser
I forbindelse med s}vel alarmterminaler som vagtcentraler findes en
r{kke t{llere og gr{nser, som kan afl{ses og opdateres fra DC.
Det drejer sig om:
- transmissionsfejlt{ller
- pakket{ller
- max succ liniefejl
- servicegr{nse
- stop poll gr{nse
Pakket{lleren kan kun afl{ses, den kan ikke opdateres.
«eof»