DataMuseum.dk

top - metrics - download

    Length: 64512 (0xfc00)
    Types: TextFile
    Names: »brufu«

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

TextFile

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