Fallstudie: Digitale Alarmierung über POCSAG in ZABOS

Anfang 2015 bekamen wir den Auftrag, unser SMS-Alarmierungssystem ZABOS um die Möglichkeit einer digitalen Alarmauslösung zu erweitern. Dieser Blog-Eintrag soll einige Hintergründe unserer Entwicklungsarbeit erläutern.

Einführung zu den unterschiedlichen Alarmierungsarten

Alarmierungen von Piepern oder Alarmsirenen kann analog oder digital geschehen. In Deutschland kommt bei der analogen Alarmierung der Fünf-Ton-Folgeruf zum Einsatz. Digital wird über POCSAG oder TETRA alarmiert.

Analoge Alarmierung per 5-Ton-Folgeruf

Der 5-Ton-Folgeruf wird innerhalb des 4m-Bandes versendet. Ein 5-Ton ist durch die Leitstelle einer Schleife oder einer Person zugeordnet. Auf Protokollebene wird zuerst eine Präambel und danach zweimalig der auszulösende 5-Ton gesendet. Die Kodierung des 5-Tons erfolgt anhand von unterschiedlichen Tonhöhen bzw. Frequenzen. Die unterschiedlichen Tonhöhen sind in Deutschland durch den ZVEI-Standard definiert.

Die Fünfton-Alarmierung ist aus technischer Sicht relativ einfach zu implementieren: Für die erste Version von ZABOS im Jahr 2006 haben wir die Dekodierung der 5-Ton-Folgerufe über einen einfachen ATmega128/L gelöst. Die Firmware wandelte die analogen Signale in verwertbare digitale Signale um und sandte sie über die serielle Schnittstelle an das ZABOS-System. Um zukunftsfähig zu bleiben, entschieden wir uns Anfang 2010 den Mikrocontroller durch die Nutzung eines Funkscanners und der Soundkarte abzulösen.

Problematisch ist bei der Alarmierung über 5-Ton, dass keine verschlüsselten Nachrichten gesendet werden können. Jede Person, die die Funkfrequenz für die 5-Ton-Alarmierungen kennt, kann die Alarme mitlesen. Außerdem ist die Anzahl der verfügbaren Schleifen bzw. Fünftöne prinzipbedingt auf 10^5 (5 Stellen mit je 10 Ziffern) begrenzt. In der Praxis ist dies durch die eingeschränkte Reichweite aber eher zu vernachlässigen.

Digitale Alarmierung per POCSAG

POCSAG steht für Post Office Code Standardization Advisory Group und ist eine Form der digitalen Alarmierung.  Anstelle des 4m-Bandes nutzt POCSAG das 2m-Band.

Das Protokoll wird nicht nur von BOS-Strukturen eingesetzt, sondern kommt auch beispielsweise bei Taxizentralen zum Einsatz. Die Adressierung von Schleifen erfolgt über den Radio Identification Code (RIC) und die Sub-RIC. Die RIC besteht aus 7 Ziffern, für die Sub-RIC stehen die Zeichen 1-4 bzw. a-d in der Darstellung zur Verfügung. Eine Sub-RIC dient zur weiteren Granulierung innerhalb der Schleife. So kann die Sub-RIC 1 den Einsatz auslösen, die 2 hingegen den Einsatz abbrechen. Die Bedeutung der Sub-RICs kann von Schleife zu Schleife unterschiedlich sein.
Im Gegensatz zur analogen Alarmierung per Fünfton können über POCSAG auch Nachrichten gesendet werden. Im Standard sind die Datenraten 512, 1200 und 2400 bps definiert. Somit können auch längere Texte oder Meta-Informationen schnell übertragen werden. Außerdem können die Alarmtexte verschlüsselt werden. Die Verschlüsselung ist aber nicht Teil des Standards und erfolgt durch den Hersteller der Funkempfänger und -sender. Neben der symmetrischen Verschlüsselung durch AES kommt der DiCal-IDEA-Algorithmus zum Einsatz, der in den Geräten des Herstellers Swissphone eingesetzt wird. DiCal-IDEA ist eine erweiterte und patentierte Form des IDEA-Algorithmus und kann somit nicht ohne Weiteres in Fremdsoftware implementiert werden.

Das zugrunde liegende Protokoll von POCSAG erinnert von dem Aufbau her an Ethernet II. Auf eine Preambel folgen so genannte Batches, die aus einzelnen Codeworten bestehen. Jedes Codewort besteht aus 4 Byte. Unterschieden wird zwischen Address Code Words und Message Code Words. Address Code Words beinhalten die zu alarmierende (Sub-)RIC. Alarmierungstexte werden innerhalb der Message Code Words übertragen. Es kommt dabei eine 7 Bit-ASCIII-Kodierung zum Einsatz. Die Übertragung von Umlauten ist somit nicht vorgesehen. Ein Hersteller von Sendern und Empfängern kann aber durchaus einen anderen Zeichensatz implementieren.

Die Einfachheit des Protokolls schlägt sich auch in der benötigten Anzahl von Seiten zur Beschreibung nieder: Raveon benötigt in ihrer Beschreibung zum POCSAG-Protokoll nur sechs Seiten.

Bereits vor einigen Jahren wurde an uns der Plan herangetragen, dass im Raum Gifhorn die analoge Alarmierung auf den Digitalempfang umgestellt werden sollte. Um zukunftssicher zu bleiben, entschieden wir uns damals, den Empfang der analogen Signale über die Open Source-Software monitord zu lösen. Sie unterstützt sowohl ZVEI als auch POCSAG. Im Rahmen der Integration in ZABOS wurde von uns die Anbindung an den Message Broker ActiveMQ entwickelt und als Open Source veröffentlicht.

Digitale Alarmierung über TETRA und Alternativen

Anders als bei POCSAG ist bei TETRA die bidirektionale Kommunikation vorgesehen: Alarmierende können sich somit beim Auslösenden zurückmelden. TETRA verfügt über mehr Protokollebenen als POCSAG und ist deutlich komplexer. Der technische Report von ETSI zum TETRA-Protokoll besteht aus 188 Seiten. Eine einfache und schnelle Implementierung ist damit nicht möglich. Das Osmocom TETRA-Projekt hat sich trotzdem dieser Aufgabe angenommen, damit auch privaten Anwendern die Möglichkeit haben, das Protokoll zu nutzen. Hier sei auch die Chaosradio Express Podcast in der Folge 183 empfohlen, in der Harald Welte die Grundlagen des Bündelfunks erklärt.

Aus unserer begrenzten Entwicklersicht ist TETRA eher als ein teures Konkurrenzprodukt zu Mobilfunktechnologien wie GPRS, UMTS oder LTE zu sehen.

POCSAG-Alarmierungen empfangen

Bei der Integration von POCSAG in ZABOS probierten wir zunächst zwei unterschiedliche Ansätze aus, wie die POCSAG-Alarmierungen empfangen werden konnten. In beiden Fällen wurde eine externe Antenne zur Verstärkung des Empfangssignals benötigt.

Funkscanner und Soundkarte

Wir testeten zuerst die Kombination aus UNIDEN Bearcat UBC355CLT und einer Soundkarte. Nach Problemen mit diversen Soundkarten – der Ausgang des Bearcats lieferte kein Signal – kam eine altgediente TerraTec 128i zum Einsatz. Die Einstellungen zum Empfang eines sauberen Signals dauerten äußerst lange. Außerdem hatten wir durch den Funkscanner eine weitere mögliche Fehlerquelle im System.

RTL-SDR

Der zweite Ansatz war der Empfang über einen DVB-T-Stick. Mit der passenden Software konnten wir die Signale automatisch einmessen. Die Funksignale wurden dann über eine virtuelle Soundkarte innerhalb des Betriebssystems zur Verfügung gestellt.

Kompilierung von RTL-SDR

Konfiguration des DVB-T-Sticks

Nach der Kompilierung von rtl-sdr steht das Tool rtl_fm zur Verfügung. Mit ihm lässt sich für den DVB-T-Stick die Frequenz einstellen, auf der die POCSAG-Alarme gesendet werden.

Aufnahme der POCSAG-Signale

Um die Signale vom DVB-T-Stick umzuwandeln, muss zuerst eine virtuelle Soundkarte eingerichtet werden. Dies geschieht mit

Um die virtuelle Soundkarte anzusprechen, kann die Syntax hw:Loopback:x:y genutzt werden, wobei x für das Subdevice steht. Weiterhin ist Subdevice 1 der Input und 0 der Output.

Zum Aufnehmen muss also das Device hw:Loopback:1:0 genutzt werden, zur Wiedergabe hw:Loopback:0.0.

aplay spielt nun die eingehenden Signale des DVB-T-Sticks von hw:Loopback,1,0 über das virtuelle Sounddevice hw:Loopback,0,0 ab. Die virtuelle Soundkarte besitzt im Gegensatz zu realen Geräten keine Mixer-Controls. Ein Entmuten ist daher nicht nötig bzw. möglich.

Empfang mit monitord

Während des Testens konnten Signale mit einer anderen Samplingrate als 48 kHz von monitord nicht dekodiert werden. Aus diesem Grund sind die beiden Parameter -s 48000 für rtl_fm bzw. -r 48000 für aplay wichtig.

monitord kann nun über den passenden Konfigurationseintrag in der monitord.xml die Daten von der virtuellen Soundkarte abgreifen und verarbeiten:

Alternativen

Das POCSAG-Gateway von Rene Wolf ist eine externe Box, die POCSAG-Signale empfängt und per HTTP-Request weiterleiten kann. Wir haben uns vorläufig gegen den Kauf entschieden, da wir weiterhin auf die monitord-Lösung setzen wollten.

Eine flexible Architektur durch monitord und ActiveMQ

Durch die bereits vorhandene Integration der ActiveMQ-Schnittstelle in monitord konnten wir den programmiertechnischen Teil der POCSAG-Erweiterung von ZABOS schnell umsetzen. monitord nimmt das Audiosignal von der internen (virtuellen) Soundkarte auf, analysiert dieses und wandelt es in eine verwertbare Struktur um. Danach wird die umgewandelte POCSAG-Nachricht über die Message Queue an ActiveMQ gesendet und durch einen Message Listener von ZABOS empfangen.

Innerhalb von ZABOS sind die RICs bzw. Sub-RICs zu den auszulösenden Schleifen hinterlegt. Die Alarmierung per SMS erfolgt bei eingegangenem POCSAG-Alarm sofort.

Für die Entwicklung und den Betrieb bietet die Nutzung der Message Queue mehrere Vorteile:

  • Der Parallelbetrieb von analoger und digitaler Alarmierung ist möglich, da unterschiedliche Queues für den Versand/Empfang der Alarme genutzt werden.
  • Die Integrationstests der POCSAG-Implementierung in ZABOS konnte bereits ohne vorhandene Hardware geschehen. Die Struktur der eingehenden POCSAG-Nachrichten ist definiert, so dass Testnachrichten an eine Message Queue gesendet werden konnten.
  • Durch die Nutzung eines definierten Datenformats kann die Applikation zum Umwandeln der POCSAG-Nachrichten bei Bedarf ausgetauscht werden.

Fazit

Mit der Version 1.4.0 von ZABOS konnte die Alarmauslösung per POCSAG erfolgreich implementiert werden. Das Produktivsystem wurde Anfang September 2015 auf die neue Version aktualisiert. Die analoge Alarmierung über Fünfton wurde durch POCSAG abgelöst.