Cirkulære nr. 29D. Tilslutning af fjernovervågningsudstyr til det offentlige alarmsystem. Tilslutning af vagtcentraler til det offentlige alarmsystem

Cirkulære nr. 29D. Tilslutning af fjernovervågningsudstyr til det offentlige alarmsystem. Tilslutning af vagtcentraler til det offentlige alarmsystem

0. Indholdsfortegnelse side 1. Almindeligt................................................. 1 2. Funktionsbeskrivelse........................................ 2 3. Transmissionsformater....................................... 2 4. Informationsfelt <INFO>..................................... 3 4.1 <meddelelsestype>........................................... 3 4.2 <adresse>................................................... 3 4.3 <databyte>.................................................. 3 4.4 Behandling af meddelelsestyper til VC ...................... 4 4.5 Behandling af meddelelsestyper fra VC...................... 10 4.6 Afvisning af meddelelser................................... 12

5. Kontrol af forbindelse mellem VC og alarmsystem............ 12 1. Almindeligt

Forbindelsen mellem vagtcentral og alarmsystem kan enten være en 1200 bit/s fuld duplex forbindelse eller en 150 bit/s halv duplex forbindelse. En skematisk fremstilling af en vagtcentrals tilslutning til alarmsystemet er vist i fig. 1 og 2.

Mellem det privatejede vagtcentraludstyr og alarmsystemet er en grænseflade som vist på figurerne.

Til vagtcentraludstyret stilles det generelle krav, at udstyret er konstrueret til at kommunikere med

alarmsystemet over dette grænsesnit, dvs. kan udføre de for kommunikation nødvendige funktioner, der er beskrevet i dette cirkulære samt cirkulære nr. 29E, henholdsvis cirkulære nr. 29F. Hver AU kan være tilknyttet flere vagtcentraler. Af disse har een VC speciel status, den såkaldte primære VC, PVC. Den modtager de alarmer, som sendes uden adressebyte, men også en kopi af de alarmer, som sendes til alternative VC'er (AVC). Desuden er det kun PVC, der modtager linie- og statusalarmer.

Endelig kan en VC flytte sin vagt til en anden (forudbestemt) VC efter en kvitteringssekvens mellem vagtcentralerne. Denne vagtflytning må ikke forveksles med sending til AVC; såvel PVC som AVC kan flytte sin vagt. Overfører en PVC sin vagt til en VC, som er AVC for nogle af PVC's abonnenter, bliver den både PVC og AVC for disse abonnenter.

2. Funktionsbeskrivelse

Vagtcentraler tilsluttet alarmsystemet via en fuld duplex forbindelse kommunikerer med dette ved hjælp af en protokol, som er beskrevet i cirkulære nr. 29E.

Vagtcentraler tilsluttet alarmsystemet via en halv duplex forbindelse kommunikerer med dette ved hjælp af en protokol, som er beskrevet i cirkulære nr. 29F.

I begge kommunikationsformer anvendes blokorienterede transmissionsformater, som beskrives i det efterfølgende.

3. Transmissionsformater

De formater, der anvendes i kommunikationen mellem vagtcentral og alarmsystem, er fælles for henholdsvis fuld duplex og halv duplex tilslutning. Transmissionsformatet er karakteriseret ved et blokformat og et tegnformat.

3.1 Blokformat

De blokke, der transmitteres over grænsesnittet, skal være opbygget på følgende måde

<STX><OPK><BBL><INFO><ETX><CHS>

undtagen for visse værdier af <OPK>, hvor <BBL> og <INFO> ikke forefindes, se senere.

<STX> markerer starten på en blok, værdi lig med 02H (H = Hexadecimal).

<OPK> er en operationskode, som angiver, om blokken skal opfattes som en kommando eller en kvittering.

<OPK> kan antage følgende værdier

Kommandoer

ENQ = 05 H POLL-0 = 11 H POLL-1 = 12 H DATA-0 = 1CH DATA-1 = 1DH Kvitteringer: ACK-0 = 13 H ACK-1 = 14 H RESET = 15 H DATA-0 = 1E H DATA-1 = 1F H

Kun når en blok indeholder en <OPK> = DATA-0 eller DATA-1, indeholder den <BBL> (se senere) og <INFO> (se senere).

<BBL> angiver længden af <INFO> minus 1, målt i byte, og skal være større end eller lig med 15 og mindre end eller lig med 116.

<INFO> indeholder den information, der skal overføres.

Antallet af byte i <INFO> skal være større end eller lig med 16 og mindre end eller lig med 117 byte.

<ETX> markerer afslutningen på blokken, værdi lig med 03H.

<CHS> er 1 byte, der tjener til check af transmissionsfejl. <CHS>- byten fremkommer ved addition modulo 256 af de enkelte byte i blokken, fra og med <STX> til og med <ETX>.

3.2 Tegnformat

De blokke, der transmitteres mellem vagtcentral og alarmsystem, er sammensat af 4 eller 21-122 tegn. Hvert tegn består af 1 startbit, 8 informationsbit (mindst betydende bit sendes først), 1 paritetsbit (der anvendes ulige paritet) og 2 stopbit.

4. Informationsfelt <INFO>

<INFO> har følgende format

<meddelelsestype> <adresse 1> <adresse 2> <databyte> 106/5

Skematisk kan <INFO> udtrykkes således

4.1 <meddelelsestype>

<meddelelsestype> er eet tegn, der angiver, hvorledes de efterfølgende tegn i <INFO> skal fortolkes. <meddelelsestype> kan opdeles i 16 funktionsgrupper, som angivet i cirkulære nr. 29I.

4.2 <adresse>

<adresse> er en BCD-streng på 5 tegn indeholdende en 10-cifret abonnentadresse, hvor første ciffer altid er 0, dvs. den egentlige abonnentadresse er på 9 cifre.

<adresse>-felterne i <INFO> skal tolkes således

4.3 <databyte>

<databyte> indeholder den information, som skal overføres. Den kan indeholde fra 5 til 106 byte.

4.3.1 < update> <result>

I databyte-delen forekommer en byte, der repræsenterer to koder: En opdateringskode og en resultatkode.

Opdateringskoden fylder 3 bit, og resultatkoden fylder 5 bit.

Det er disse felter i en enkelt byte, der refereres til, når der i det følgende skrives henholdsvis

<update> og <result>.

Begge koder bruges for visse meddelelsestyper til at uddybe meddelelsens betydning. I afsnit 4.4 og 4.5 vil det under beskrivelsen af den enkelte meddelelsestype være angivet ved <update> henholdsvis <result>, om der skal tillægges opdateringskoden henholdsvis resultatkoden en betydning for den aktuelle meddelelse; i disse tilfælde vil endvidere tolkningen af koderne være angivet.

Hvis der ikke skal tillægges disse koder en betydning, angives dette i teksten ved et »0« i stedet for < update> henholdsvis et »0« i stedet for <result>.

4.3.2 <tidspunkt>

Endvidere er der afsat 4 byte til <tidspunkt>, der angiver tidspunktet for meddelelsens afsendelse.

<tidspunkt> er pakket således

Grunden til, at sekunder i <tidspunkt> er divideret med 2, er, at der kun er 5 bit til rådighed, hvilket kun giver mulighed for at repræsentere værdier i intervallet 0...31.

4.4 Behandling af meddelelsestyper til VC

VC skal ved modtagelse af visse meddelelser kvittere tilbage til alarmsystemet. <adresse 1> og <adresse 2> skal i disse kvitteringer være en kopi af <adresse 1> og <adresse 2> i den meddelelse, der kvitteres for.

For kvitteringer for meddelelser gælder generelt, at hvis kvitteringer skal foregå automatisk, er timeoutperioden 30 sekunder - ved manuel kvittering er timeoutperioden 5 minutter.

Under beskrivelsen af disse meddelelsestyper til VC vil det være angivet, om VC skal kvittere automatisk (uden operatørindgriben) eller manuelt (med operatørindgriben).

Generelt skal meddelelser til VC betragtes som nonsens, hvis

- meddelelsestypen er ukendt

- meddelelsestypen er kendt, men adresser eller updatekoder eller resultkoder ikke passer ind i de for denne meddelelsestype angivne intervaller.

I det følgende beskrives for flere meddelelsestyper, hvorledes resultatkoden skal fortolkes i VC. Nogle resultatkodeværdier betyder fejlsituation. Hvis en sådan fejlsituation opstår, og VC anser fejlen for at ligge i alarmsystemet, bør VC rapportere fejlen til teleadministrationen med angivelse af den aktuelle meddelelses eksakte indhold.

01H: Log til PVC <adresse 1> = afsender-AT'ens adresse <adresse 2> = AVC-adresse databyte (1) = 0, <result> databyte (2)-(5) = tidspunkt databyte (6)- (5 + <antal byte>) = alarm hvor <antal byte> højst kan være 16 byte.

VC er PVC for AT'en, som har sendt en alarm til en AVC, og VC modtager hermed som PVC en logning (kopi) af alarmen (hvis VC er både PVC og AVC for AT'en, sendes O1H ikke).

<result> skal tolkes, som følger

<result> = 0 og 5 Opsamling af alarm fra AU gik OK. <result> = 9 Fejl i alarmudstyret: PVC modtager alarmen, fordi AU har afleveret en ukendt adressekode. <result> = 15 Fejl i alarmudstyret: AU afleverer ikke det antal byte, som er specificeret for afsendelse af alarm til den aktuelle VC <result> = 21 Fejl i alarmudstyret: AU afbryder afsendelsen af den aktuelle alarm ved at sende et adresseskift. <result> = 13, 22 og 23 Fejl i alarmsystemet. <result> = 20 Dataopsamling afbrudt af statusalarm. <result> = 17, 19 og 25 Fejl, der ikke umiddelbart kan placeres. VC-operatør bør tage kontakt til teleadministrationen for fejllokalisering. VC skal ikke kvittere. 12H:- Afvist meddelelse <adresse 1> = adressen, hvor meddelelsen afvises <adresse 2> = adressen, hvortil meddelelsen oprindelig blev sendt databyte (1) = 0, <result> databyte (2) - (5) = tidspunkt databyte (6)- (5+<tekstlængde>) = gamle data hvor <tekstlængde> højst kan være 100 byte.

VC har sendt en meddelelse, som af en eller anden grund ikke er nået frem til modtageren enten på grund af, at meddelelsen er fejlbehæftet fra VC's side, eller på grund af manglende forbindelse eller ressourcer i alarmsystemet.

<result> skal tolkes, som følger

<result>= 1, 2, 3 og 24 VC har sendt en meddelelse til alarmsystemet, hvori der anmodes om udførelse af en funktion, alarmsystemet ikke kan acceptere. Meddelelsen fra VC afvises hermed. <result>= 5, 9, 20, 21, 22, 29, 30 og 31 Fejlbehæftet meddelelse fra VC:. VC har sendt en fejlbehæftet meddelelse (f.eks. en meddelelse, hvor adresse 1 eller 2 er ukendt); denne meddelelse afvises hermed. <result>= 13, 16, 17 og 23 Manglende forbindelse i alarmsystemet:. VC har sendt en meddelelse, der p.g.a. manglende forbindelse i alarmsystemet ikke kan nå frem til den specificerede modtager; meddelelsen afvises hermed. <result>= 7, 14 og 18 Manglende ressourcer i alarmsystemet: VC har sendt en meddelelse, der på grund af manglende ressourcer i alarmsystemet ikke kan nå frem til den specificerede modtager; meddelelsen afvises hermed. Manglende ressourcer kan opstå i situationer, hvor der sendes ekstraordinært mange meddelelser i alarmsystemet. Fænomenet er af forbigående karakter, og VC vil derfor ved gensending af den oprindelige meddelelse sandsynligvis ikke opleve endnu en afvist meddelelse 12H.

De omtalte »gamle data« indeholder den meddelelse, der er blevet sendt fra VC.

»Gamle data« er med følgende undtagelser altid en kopi af den meddelelse, VC har sendt

- Hvis den oprindelige meddelelse fra VC var længere end 101 byte, vil de byte, der blev sendt ud over 101 byte, være bortfaldet i den afviste meddelelse.

- Hvis adresser, resultatkode, opdateringskode i den oprindelige meddelelse skulle have været nulstillet af VC som beskrevet i afsnit 4.5, og VC har undladt at gøre dette, vil de være blevet nulstillet i »gamle data«.

- Tidspunktet i den oprindelige meddelelse kan være ændret.

VC skal ikke kvittere.

20H: Forbindelse til DC er væk <adresse 1> = 0 <adresse 2> = DC-adresse databyte (1) = 0,0 databyte (2)-(5) = tidspunkt VC skal ikke kvittere. 21H: Forbindelse til DC er oprettet <adresse 1> = 0 <adresse 2> = DC-adresse databyte (1) = 0,0 databyte (2)-(5) = tidspunkt VC skal ikke kvittere. 22H: Forbindelse til NC er væk <adresse 1> = 0 <adresse 2> = NC-adresse databyte (1) = 0,0 databyte (2)-(5) = tidspunkt VC skal ikke kvittere. 23H: Forbindelse til NC er oprettet <adresse 1> = 0 <adresse 2> = NC-adresse databyte (1) = 0,0 databyte (2)-(5) = tidspunkt VC skal ikke kvittere. 24H: Forbindelse til TS er væk <adresse 1> = 0 <adresse 2> = TS-adresse databyte (1) = 0,0 databyte (2)-(5) = tidspunkt VC skal ikke kvittere. 25H: Forbindelse til TS er oprettet <adresse 1> = 0 <adresse 2> = TS-adresse databyte (1) = 0,0 databyte (2)-(5) = tidspunkt VC skal ikke kvittere. 28H: AT-moduludfald <adresse 1> = 0 <adresse 2> = alarmsystemadresse databyte (1) = 0,0 databyte (2)-(5) = tidspunkt

Hvis mikroadresse i <adresse 2> = 1, er alle AT' er med den pågældende makroadresse faldet ud.

Hvis mikroadresse i <adresse 2> modulo 256 = 1, er alle AT'er i intervallet (mikroadresse i <adresse 2> - 1) + 32...255 faldet ud. Hvis mikroadresse i <adresse2> modulo 256 = 32...255 er AT'en med den pågældende adresse faldet ud.

VC skal ikke kvittere.

29H: AT-modulgenoprettelse <adresse 1> = 0 <adresse 2> = alarmsystemadresse databyte (1) = 0,0 databyte (2)-(5) = tidspunkt Bemærkninger analogt til meddelelsestype 28H. VC skal ikke kvittere. 2CH: AMUX-udfald <adresse 1> = 0 <adresse 2> = AMUX-adresse databyte (1) = 0,0 databyte (2)-(5) = tidspunkt Alle AT'er i intervallet mikroadresse i <adresse 2> + 32...255 er faldet ud. VC skal ikke kvittere. 2DH: AMUX-genoprettelse <adresse 1> = 0 <adresse 2> = AMUX-adresse databyte (1) = 0,0 databyte (2)-(5) = tidspunkt Bemærkninger analogt til meddelelsestype 2CH. VC skal ikke kvittere. 30H: AU-alarm <adresse 1> = AT-adresse <adresse 2> = 0 databyte (1) = 0, <result> databyte (2)-(5) = tidspunkt databyte(6)- (5+<antal byte>) = alarm hvor <antal byte> højst kan være 16 byte. <result> skal tolkes som ved meddelelsestype O1H. VC skal ikke kvittere. 31H: Liniealarm <adresse 1> = AT-adresse <adresse 2> = 0 databyte (1) = 0,0 databyte (2)-(5) = tidspunkt databyte (6) = alarmkode <alarmkode> tolkes således: 0: Linien OK 1...5: Fejl på linien mellem AT og alarmsystem. VC skal ikke kvittere. 32H: Statusalarm <adresse 1> = AT-adresse <adresse 2> = 0 databyte (1) = 0,0 databyte (2) = tidspunkt databyte (6) = statusbyte <statusbyte> tolkes således: Bit 0: Fejl i AT's hovedstrømforsyning. Bit 1: Fejl i AT's reservestrømforsyning. Bit 2: AT er restartet, dvs. at tidligere information er glemt. Bit 3: Fejl i kommunikation mellem AT og AU. Bit 4: AU indikerer, at AU er upålidelig. Bit 5: Fejl i handshake mellem AT og AU. Bit 6: AT har ikke modtaget poll i en periode på mere end ca. 9 sekunder. Bit 7: Bruges ikke. Er en bit logisk 1, er den pågældende fejl opstået. VC skal ikke kvittere. 41H: Kvittering for styring <adresse 1> = AT-adresse <adresse 2> = 0 databyte (1) = 0, <result> databyte (2)-(5) = tidspunkt databyte (6)- (5+<antal byte>) = styring hvor <antal byte> højst kan være 16 byte. VC har sendt en styring og får her en kvittering tilbage fra alarmsystemet. <result> skal tolkes, som følger: <result> = 0 Styringen er afleveret til AU. <result> = 6 VC har ikke styretilladelse for denne AT. <result> = 13, 14, 16...18 og 21...23 Fejl i alarmsystemet. <result> = 26 og 27 Fejl i AU. <result> = 20 Dataopsamling afbrudt af statusalarm. <result> = 12, 15, 19 og 25 Fejl, der ikke umiddelbart kan placeres. VC-operatøren bør tage kontakt til teleadministrationen for fejllokalisering. VC skal ikke kvittere. 45H: Kvittering for gruppestyring <adresse 1> = alarmsystemadresse <adresse 2> = 0 databyte (1) = 0, <result> databyte (2)-(5) = tidspunkt databyte (6)-(7) = AT-mikroadresse nedre grænse databyte (8)-(9) = AT-mikroadresse på den sidste styrede AT databyte (10)-(11) = AT-mikroadresse øvre grænse databyte (12)- (11 + <antal byte>) = styring hvor <antal byte> højst kan være 16 byte.

VC har sendt en gruppestyring.

Hvis alarmsystemet udfører gruppestyringen, vil VC modtage en kvittering for hver AT, hvor styringen ikke gik godt. For disse kvitteringer gælder det, at meddelelsestypen er 45H, mikroadresse i <adresse 1> modulo 256 = 32...255 angivende den pågældende AT, og formatet af meddelelser er som for 41H.

Det gælder endvidere, at resultatkoden skal tolkes som for 41H. VC vil ikke modtage sådanne kvitteringer for de AT'er, hvor styringen gik godt.

VC vil altid modtage en 45H, hvori mikroadressen i <adresse 1> modulo 256 = 1.

<result> skal tolkes, som følger

<result> = 0 Gruppestyring udført. <result> = 6 VC har ikke styretilladelse for AT'er i dette interval. <result> = 16 og 17 Fejl i alarmsystemet. VC skal ikke kvittere. 50H: Anmodning om vagtflytning <adresse 1> = DC-adresse <adresse 2> = VC-adresse databyte (1) = 0,0 databyte (2)-(5) = tidspunkt VC spørges, om den vil modtage vagten for VC i <adresse 2>. Der skal kvitteres (accept eller ikke) med en meddelelsestype 51H tilbage til DC-adressen angivet i <adresse 1>. VC skal kvittere manuelt. 51H: Kvittering for anmodning om vagtflytning <adresse 1> = DC-adresse <adresse 2> = VC-adresse databyte (1) = 0, <result> databyte (2)-(5) = tidspunkt

VC har anmodet om at få flyttet sin vagt til VC i <adresse 2>.

DC svarer med en meddelelsestype 51H, når

- VC i <adresse 2> har svaret ikke accept.

- VC i <adresse 2> har svaret accept, og når vagtflytning er forsøgt udført.

<result> skal tolkes, som følger

<result> = 0 Vagtflytningen til VC i <adresse 2> er foretaget. VC vil nu ikke modtage alarmer. <result> = 1...31 Vagtflytning til VC i <adresse 2> er ikke foretaget, enten fordi VC har sendt en fejlbehæftet meddelelse »anmodning om vagtflytning«, eller fordi der er fejl i alarmsystemet, eller fordi VC i <adresse 2> har svaret nej til at overtage vagten over VC's AT'er. VC skal ikke kvittere. 55H: Kvittering for anmodning om vagtreturnering <adresse 1> = DC-adresse <adresse 2> = VC-adresse databyte (1) = 0, <result> databyte (2)-(5) = tidspunkt VC har anmodet om at fÅ sin vagt returneret fra VC i <adresse 2>, som vagten tidligere er blevet flyttet til. <result> skal tolkes, som følger: <result> = 0 Vagten er nu returneret til VC. VC kan igen modtage alarmer. <result> = 1...31 Vagtreturnering til VC er ikke foretaget, enten fordi VC har sendt en fejlbehæftet meddelelse »anmodning om vagtreturnering«, eller fordi der er fejl i alarmsystemet. VC skal ikke kvittere. 58H: Meddelelse om vagtreturnering <adresse 1> = VC-adresse <adresse 2> = VC-adresse databyte (1) = 0,0 databyte (2)-(5) = tidspunkt

VC i <adresse 1> har haft vagten for VC i <adresse 2>, og meddelelsestype 58H betyder, at VC i <adresse 1> ikke længere kan modtage alarmer sendt til VC i <adresse 2>.

Både VC i <adresse 1> og i <adresse 2> modtager 58H.

VC skal ikke kvittere.

64H: Anmodning om tilladelse til start eller stop poll af AT <adresse 1> = adressen på AT's DC <adresse 2> = AT-adresse databyte (1) = < update>, 0 databyte (2)-(5) = tidspunkt

Når 64H sendes, meddeler alarmsystemet, at det ønsker poll startet eller stoppet.

<update> angiver, om det drejer sig om start eller stop

<update> = 0: Start poll. <update> = 1: Stop poll.

Hvis VC også ønsker poll startet/stoppet, sendes manuelt meddelelsestype 64H med samme <update> til alarmsystemet. Ellers gøres intet.

66H: Anmodning om nedlæggelse af AT <adresse 1> = DC-adresse <adresse 2> = AT-adresse databyte (1) = 0,0 databyte (2)-(5) = tidspunkt

VC skal kvittere manuelt med meddelelsestype 67H, om anmodningen accepteres eller ej.

72H: Anmodning om nedlæggelse af VC <adresse 1> = adressen på VC's DC <adresse 2> = 0 databyte (1) = 0,0 databyte (2)-(5) = tidspunkt Anmodningen gælder VC. VC skal kvittere manuelt med meddelelsestype 73H. 85H: Kvittering for ekstern test <adresse 1> = AT-adresse <adresse 2> = 0 databyte (1) = 0, <result> databyte (2)-(5) = tidspunkt databyte (6) = testsvarbyte VC har ønsket en ekstern test på en AT. <result> skal tolkes, som følger: <result> = 0 Ekstern test udført. <result> = 24 VC har ikke tilladelse til at udføre ekstern test på denne AT <result> = 11, 26 og 27 Fejl i alarmudstyret. <result> = 13, 14, 16, 18, 19 og 21...23 Fejl i alarmsystemet <result> = 20 Dataopsamling afbrudt af statusalarm. <result> = 12, 15, 17 og 25 Fejl, der ikke umiddelbart kan placeres. VC-operatør bør tage kontakt med teleadministrationen for fejllokalisering. VC skal ikke kvittere. 98H: Generel meddelelse <adresse 1> = afsenderens adresse <adresse 2> = 0 databyte (1) = 0,0 databyte (2)-(5) = tidspunkt databyte (6)- (5+<tekstlængde>) = tekststreng hvor <tekstlængde> højst kan være 80 byte. NB: Tekststrengen afsluttes med 2 byte med værdien nul. VC skal ikke kvittere. 9BH: AT-beskrivelse <adresse 1> = DC-adresse <adresse 2> = AT-adresse databyte (1) = 0,0 databyte (2)-(5) = tidspunkt databyte (6) = løbenummer databyte (7)- (6+infolængde>) = beskrivelse hvor <infolængde> er 72 byte eller 44 byte afhængigt af løbenummer. For løbenummer = 1: databyte (7)-(42) = abonnentens navn (ASCII-tegn) databyte (43)-(78) = abonnentens adresse (ASCII-tegn) For løbenummer = 2: databyte (7)-(42) = abonnentens by (ASCII-tegn) databyte (43) = AMUX-nummer databyte (44) = AMUX-port nr. databyte (45) = AT-type databyte (46) = poll-tilstand 0: Poll er startet 1: Poll er stoppet databyte (47)-(48) = servicegrænse databyte (49)-(50) = stop poll grænse

VC har anmodet (med en meddelelsestype 9AH) om en AT-beskrivelse. VC modtager derfor først 9BH med løbenummer = 1 og dernæst 9BH med løbenummer 2.

VC skal ikke kvittere.

A2H: Opdatering af AT-adressetabel <adresse 1> = DC-adresse <adresse 2> = AT-adresse databyte (1) = <update>, 0 databyte (2)-(5) = tidspunkt

<update> angiver, om det drejer sig om at indsætte i eller fjerne fra VC's AT-adressetabel.

<update> = 1: lndsæt

<update> = 3: Fjern

VC skal kvittere automatisk med en meddelelsestype A3H med samme

<update> samt et <result>, der angiver, hvordan opdateringen er gået.

C0H: Knudetest <adresse 1> = 0 <adresse 2> = 0 databyte (1) = 0,0 databyte (2)-(5) = tidspunkt databyte (6)-(7) = knudetestens løbenummer (cyklisk forløb) databyte (8)-(9) = antal sekunder, der vil forløbe, indtil VC modtager næste knudetest databyte (10)-(11) = tolerance i sekunder på tidsangivelsen i databyte (8)-(9)

De 3 størrelser er angivet hexadecimalt, og mest betydende byte i hver af de 3 størrelser er henholdsvis nr. 6, 8 og 10.

VC skal kvittere automatisk med meddelelsestype C1H.

C8H: Forbindelsestest <adresse 1> = afsenderadresse <adresse 2> = 0 databyte (1) = 0,0 databyte (2)-(5) = tidspunkt databyte (6)- (5+<antal byte>) = identifikation

<antal byte> kan højst være 100 byte.

Identifikationen sendes tilbage i kvitteringen i en meddelelsestype C9H.

Normalt er <antal byte> i identifikationen lig med 0.

VC skal kvittere automatisk.

C9H: Kvittering for forbindelsestest <adresse 1> = 0 <adresse 2> = 0 databyte (1) = 0,0 databyte (2)-(5) = tidspunkt databyte (6)- (5+<antal byte>) = identifikation

hvor <antal byte> højst kan være 100 byte.

Denne VC har sendt en forbindelsestest til alarmsystemet og får hermed kvitteringen retur.

Identifikationen skal svare til den, der blev sendt ud i meddelelsestype C8H fra VC.

VC skal ikke kvittere.

4.5 Behandling af meddelelsestyper fra VC

40H: Styring <adresse 1> = AT-adresse <adresse 2> = 0 databyte (1) = 0,0 databyte (2)-(5) = 0 databyte (6)- (5+<antal byte>) = styring hvor <antal byte> højst kan være 16 byte. 44H: Gruppestyring <adresse 1> = TS-adresse <adresse 2> = 0 databyte (1) = 0,0 databyte (2)-(5) = 0 databyte (6)-(7) = AT-mikroadresse nedre grænse databyte (8)-(9) = AT-mikroadresse øvre grænse databyte (10)- (9+<antal byte>) = styring hvor <antal byte> højst kan være 16 byte.

Det er kun muligt at gruppestyre på een AMUX ad gangen, hvorfor øvre og nedre mikroadresse skal ligge på samme AMUX - dvs. mikroadresse i <adresse 1> heltalsdivideret med 256 skal være ens for nedre og øvre grænse.

50H: Anmodning om vagtflytning <adresse 1> = VC-adresse <adresse 2> = 0 databyte (1) = 0,0 databyte (2)-(5) = 0

VC ønsker at afgive vagten over sine AT'er til VC i <adresse 1>.

VC modtager i en meddelelsestype 51H melding om, hvordan vagtflytteanmodningen er modtaget af VC i <adresse 1>, og hvordan et eventuelt flytningsforsøg er gået.

51H: Kvittering for anmodning om vagtflytning <adresse 1> = DC-adresse <adresse 2> = VC-adresse databyte (1) = 0, <result> databyte (2)-(5) = 0

VC optræder som vagtmodtager i en vagtflytning anmodet af VC i <adresse 2>.

VC skal kvittere med

<result> = 0: Accept. <result> = 1: Ikke accept. 54H: Anmodning om vagtreturnering <adresse 1> = DC-adresse <adresse 2> = 0 databyte (1) = 0,0 databyte (2)-(5) = 0

VC har tidligere overflyttet sin vagt til en anden VC og ønsker vagten returneret.

64H: Tilladelse til start eller stop poll af AT <adresse 1> = adressen på AT's DC <adresse 2> = AT-adresse databyte (1) = <update>, 0 databyte (2)-(5) = 0

Denne VC giver sin tilladelse til start/stop poll af en AT. <update> angiver, om det drejer sig om start eller stop.

<update> = 0: Start. <update> = 1: Stop.

Hvis tilladelse ikke gives, sendes intet.

VC kan sende 64H enten som kvittering på en 64H fra DC eller på VC's eget initiativ.

Hvis VC sender meddelelsen på eget initiativ, er det kun tilladt for VC at give tilladelse til start poll. En tilladelse fra VC vil blive husket i DC's database. Før alarmsystemet sender en meddelelsestype 64H med <update> = 0 ud til VC, undersøges databasen. Hvis der i databasen findes en tilladelse fra VC, udfører alarmsystemet blot start poll uden at sende en meddelelsestype 64H ud til VC.

67H: Kvittering for anmodning om nedlæggelse af AT <adresse 1> = AT's DC-adresse <adresse 2> = AT-adresse databyte (1) = 0, <result> databyte (2)-(5) = 0 VC skal kvittere med: <result> = 0: Accept. <result> = 1: Ikke accept. 73H: Kvittering for anmodning om nedlæggelse af VC <adresse 1> = DC-adresse <adresse 2> = 0 databyte (1) = 0, <result> databyte (2)-(5) = 0 VC skal kvittere med: <result> = 0: Accept. <result> = 1: Ikke accept. 84H: Foretag ekstern test <adresse 1> = AT-adresse <adresse 2> = 0 databyte (1) = 0,0 databyte (2)-(5) = 0 databyte (6) = testbyte 98H: Generel meddelelse <adresse 1> = DC/VC-adresse <adresse 2> = 0 databyte (1) = 0,0 databyte (2)-(5) = 0 databyte (6)- (5+<tekstlængde>) = tekststreng hvor <tekstlængde> højst kan være 80 byte. 9AH: Anmodning om AT-beskrivelse <adresse 1> = DC-adresse <adresse 2> = AT-adresse databyte (1) = 0,0 databyte (2)-(5) = 0 A3H: Kvittering for opdatering af AT-adressetabel <adresse 1> = DC-adresse <adresse 2> = AT-adresse databyte (1) = <update>, <result> databyte (2)-(5) = 0 VC har tidligere modtaget en opdatering af AT-adressetabellen (meddelelsestype A2H fra alarmsystem). Kvitteringen skal indeholde samme <update> og en resultatkode, der angiver, hvordan opdateringen er gået: <result> = 0: Accept. <result> = 1: Ikke accept. C1H: Kvittering for knudetest <adresse 1> = 0 <adresse 2> = 0 databyte (1) = 0,0 databyte (2)-(5) = 0 databyte (6)-(11) = disse byte skal være lig indholdet i de tilsvarende byte i den modtagne knudetest C8H: Forbindelsestest <adresse 1> = 0 <adresse 2> = 0 databyte (1) = 0,0 databyte (2)-(5) = 0 databyte (6)- (5+<antal byte>) = identifikation hvor <antal byte> højst kan være 80 byte. C9H: Kvittering for forbindelsestest <adresse 1> = adresse på afsender af forbindelsestest <adresse 2> = 0 databyte (1) = 0,0 databyte (2)-(5) = 0 databyte (6)- (5+<antal byte>) = identifikation

hvor <antal byte> højst kan være 80 byte.

I kvitteringen skal VC sende samme identifikation, som den modtog.

4.6 Afvisning af meddelelser

Meddelelser fra VC kan afvises af alarmsystemet. Afvisninger kan forekomme dels som kvitteringer med resultatkode forskellig fra 0, og dels som afviste meddelelser (type 12H).

Meddelelser fra VC, som er af en type ikke nævnt i afsnit 4.5, vil blive afvist af alarmsystemet i en meddelelse 12H med resultatkode forskellig fra 0.

Adresser i meddelelser afsendt fra VC skal opfylde følgende minimumskrav

0 DC-adresse 15 0 NC-adresse 63 0 TS-adresse 63 0 mikroadresse 9999

Overholdes dette ikke, afviser alarmsystemet med en 12H-meddelelse med resultatkode forskellig fra 0.

Tillige skal overholdes

DC: ox-oo-oo-oooo

x har værdien fra 1 til 9.

Dog skal DC-adressen, hvis det drejer sig om en kvittering, være en kopi af den modtagne DC-adresse, idet mikroadressen kan være forskellig fra nul og derfor benyttes som særlig indikering.

NC: ox-yy-oo-oooo. yy har værdien fra 1 til 63. TS: ox-yy-yy-oooo yy har værdien fra 1 til 63. VC: ox-yy-yy-ozzz zzz har værdien fra 32 til 255. AT: ox-yy-yy-vvvv vvvv skal være større end 287, og resten af vvvv modulo 256 skal ligge mellem 32 og 255.

5. Kontrol af forbindelse mellem vagtcentral og alarmsystem

Forbindelsen mellem vagtcentral og alarmsystem kontrolleres med jævne mellemrum ved, at alarmsystemet sender en knudetest C0H til vagtcentralen, der automatisk skal svare med en kvittering for knudetest C1H.

Knudetest indeholder dels adresse for modtageren af testen og dels et

tidsrum, inden for hvilket den næste knudetest vil blive afsendt. Tidsrummet defineres af DC. Knudetest afsendes

uafhængigt af den øvrige trafik.

VC kan sende forbindelsestest C8H til alarmsystemet, som skal svare med en C9H.

Endvidere bliver selve linien overvåget på den måde, at en ændring i liniens status vil give en alarm.

Hvis linien holder op med at fungere, sendes en liniealarm til DC.

Ingen