Einführung

Das DNP3-Protokoll ist ein standardisiertes SCADA-Protokoll mit großer Verbreitung weltweit. Aufgrund seiner hohen Effizienz funktioniert es hervorragend in Umgebungen mit geringer Bandbreite und hoher Latenz, wie z. B. TETRA-Netzwerken.
Im Gegensatz zu anderen Protokollen wie MODBUS erfordert DNP3 kein regelmäßiges Polling aller Außenstationen, um Ereignisse wie geänderte binäre Eingänge, Zähler oder analoge Werte an den Außenstationen zu erfassen. Nachdem die logische Verbindung zur Außenstation hergestellt wurde, werden Ereignisse automatisch (unsolicited) an den SCADA-Server gesendet, sobald sie an der Außenstation auftreten.
Ereignisse, die innerhalb eines bestimmten Zeitrahmens auftreten, werden in der Regel gesammelt und in einem einzigen Nachrichtenrahmen gemeinsam gesendet. Wenn beispielsweise an einer Außenstation innerhalb von einer Sekunde mehrere Parameter geändert werden, werden diese Ereignisse in einem Nachrichtenrahmen kombiniert, anstatt viele einzelne Nachrichten zu erzeugen (jede mit Overhead und erforderlicher Bestätigung vom SCADA-Server). Dies hat einen erheblichen positiven Einfluss auf die Bandbreiteneinsparung in einem TETRA-Netzwerk.
Eine einzelne DNP3-Nachricht kann normalerweise bis zu 2048 Bytes lang sein, aber die Transportschicht teilt die Nachricht in kleinere Teile von bis zu 256 Bytes auf.
Es gibt zwei Implementierungen von DNP3: DNP3/IP, die IP-basierte Protokollversion, und DNP3/Serial, die eine serielle Datenverbindung nutzt.

Beide DNP3-Versionen (IP und Serial) sind so konzipiert, dass sie perfekt über ein TETRA-Netzwerk funktionieren.
 

DNP3/IP

Der DNP3/IP-Standard ermöglicht die Nutzung entweder mit TCP oder UDP als Transportprotokoll, da die Bestätigung und Wiederholung fehlender Frames vollständig vom DNP3-Protokoll selbst gehandhabt wird.
In TETRA-Netzwerken sollte UDP stets gegenüber TCP bevorzugt werden!
TCP verursacht mehr Overhead, fügt zusätzliche Bestätigungspakete hinzu, die für DNP3 nicht erforderlich sind, und die TCP-Stacks auf der Serverseite haben in der Regel keine anpassbaren Paket-Timeouts, was zu unnötigen Paketwiederholungen und Staus auf dem TETRA-Paketdatenkanal führen kann.
 

Anforderungen für DNP3/IP in TETRA
Verbindung zum Kontrollraum

Der SCADA-Server sollte eine direkte IP-Verbindung zum TETRA-Switch haben. Er nutzt das TETRA Packet Data Gateway der TETRA-Infrastruktur als Router in das drahtlose TETRA-Netzwerk. Dies eliminiert den Engpass und die hohe Latenz einer Funkverbindung auf der Kontrollraumseite. Zudem könnten die möglichen unaufgeforderten Ereignisse, die jederzeit von jeder Außenstation gesendet werden können, zu Staus und Paketverlusten führen, wenn der SCADA-Server über eine TETRA-Funkverbindung angebunden wäre.

Anforderungen an das TETRA-Netzwerk

Im TETRA-Netzwerk muss der Paketdatendienst verfügbar sein, um IP-Pakete zwischen dem SCADA-Server und den Außenstationen zu routen.
Außerdem muss jede Basisstation einen Zeitschlitz als Paketdatenkanal (PDCH) konfiguriert haben. Der PDCH sollte als „statisch“ zugewiesen werden, um einen Kommunikationsverlust im SCADA-System zu vermeiden, falls zu viele Sprachanrufe gleichzeitig aktiv sind. Die Verfügbarkeit von Notrufen ist jederzeit gewährleistet, da ein Notruf im Bedarfsfall jeden beliebigen Verkehrsschlitz „übernimmt“, falls alle Zeitschlitze zum Zeitpunkt des Notrufs belegt sein sollten.
Schließlich sollte das TETRA-Netzwerk die gemeinsame Nutzung des Paketdatenkanals (PDCH Sharing) unterstützen, um mehrere Modems gleichzeitig auf dem PDCH zu handhaben. Ohne PDCH Sharing blockiert ein einziges Modem den PDCH für den exklusiven Gebrauch während der Kommunikation sowie zusätzlich für die konfigurierte Zeit des „READY-Timers“ (in der Regel 3-5 Sekunden). Während dieser Zeit kann kein anderes Modem IP-Kommunikation auf diesem Zeitschlitz durchführen. Falls ein anderes Modem ein IP-Paket senden möchte, wird dies mit „No resources“ von der Basisstation abgelehnt, was zu einem Paketverlust führt. Mit PDCH Sharing können mindestens 32 Modems gleichzeitig auf einem einzigen PDCH betrieben werden. Die Basisstation verwaltet die effiziente Kommunikation ohne Verschwendung von TETRA-Ressourcen. In diesem Fall können an jeder Basisstation problemlos 50-100 Modems mit DNP3/IP auf einem einzigen Paketdatenkanal betrieben werden.
Mindestens ein Paketdatenkanal pro Basisstation ist für die Nutzung von DNP3/IP erforderlich.

Die gemeinsame Nutzung des Paketdatenkanals (Packet Data Channel Sharing) muss verfügbar sein, um einen einzigen PDCH für die DNP3-Kommunikation zu nutzen.

DNP3/Serial

Für DNP3/Serial können entweder Paketdaten (Packet Data) oder SDS (Short Data Service) als Transportmethode im TETRA-Netzwerk verwendet werden. Im Kontrollraum ist ein TGW-100-Gateway erforderlich, um die seriellen Schnittstellen des SCADA-Servers mit der TETRA-Infrastruktur zu verbinden und das Routing zu den Außenmodems basierend auf der in den Nachrichten gefundenen SCADA-Adresse durchzuführen. Paketdaten bieten eine bessere Fehlerbehandlung, da sie selektiv kleinere Teile einer Nachricht wiederholen können. Außerdem erfordern Paketdaten keine native SDS-API-Unterstützung des TETRA-Infrastrukturherstellers im TGW-100-Gateway.SDS-Nachrichten nutzen den Hauptsteuerkanal (Main Control Channel, MCCH) der TETRA-Basisstation für die Kommunikation. 
Für kleinere Einsätze (bis zu 20-30 Modems pro TETRA-Basisstation) sollte kein zusätzlicher Verkehrsschlitz erforderlich sein. Wenn jedoch mehr Modems an eine TETRA-Basisstation angeschlossen sind, kann der SDS-Verkehr den Steuerkanal so beeinflussen, dass z. B. Anrufaufbauten aufgrund hohen Datenverkehrs länger dauern. In diesem Fall kann ein sekundärer Steuerkanal (Secondary Control Channel, SCCH) genutzt werden, um den SCADA-Verkehr von anderen Steuerungsnachrichten zu trennen.
Da die SDS-API zum Senden und Empfangen von SDS über den TETRA-Switch nicht standardisiert ist, muss das TGW-100 die API des TETRA-Infrastrukturherstellers unterstützen.
Kleinere Einsätze mit bis zu 20 Außenstationen und Pilotprojekte können SDS auch ohne ein TGW-100-Gateway nutzen, indem ein TMO-100-TETRA-Modem auch auf der Master-Seite verwendet wird. Für den produktiven Einsatz wird jedoch ein TGW-100 empfohlen.
Wenn nicht mehr als 20-30 Modems an einer Basisstation registriert sind, kann SDS den Hauptsteuerkanal nutzen, sodass kein zusätzlicher Verkehrsschlitz für den SCADA-Dienst erforderlich ist.
Paketdaten bieten eine effizientere Fehlerbehandlung als SDS. Wenn Paketdaten bereits für andere IP-basierte Dienste genutzt werden, kann DNP3/Serial den bereits verfügbaren Paketdatenkanal (PDCH) teilen, ohne die Belastung des MCCH zu beeinträchtigen.
Paketdaten erfordern keine herstellerspezifische SDS-API-Unterstützung im TGW-100.Falls Paketdaten oder die gemeinsame Nutzung des Paketdatenkanals (Packet Data Channel Sharing) in der TETRA-Infrastruktur nicht verfügbar sind, sollte DNP3 über SDS betrieben werden, selbst wenn die Anzahl der Modems einen zusätzlichen SCCH erfordert, um die Belastung vom MCCH fernzuhalten.