DNP 3.0

  • Das DNP-Protokoll wurde für die Kommunikation mit Fernwirk-Unterstationen und anderen intelligenten elektronischen Geräten entwickelt. Es sollte speziell die damals bestehenden und zukünftigen fernwirktechnischen Bedürfnisse von Energieversorgungsunternehmen des nordamerikanischen Raums abdecken und ist dort heute in der Verwendung sehr verbreitet. Die Entwicklung erfolgte ursprünglich durch die Firma Harris, welche dann 1993 die verantwortliche Weiterentwicklung und Pflege an die DNP User Group, eine Vereinigung von Anwendern und Lieferanten des Protokolls, übergab.

    Ursprünglich wurde das Protokoll für den Einsatz auf langsamen, seriellen Kommunikationsverbindungen entwickelt. Mittlerweile wird auch die Kommunikation über TCP/IP-Netzwerke unterstützt.

    Im Gegensatz zu ähnlichen Protokollen wie IEC 60870-5-101, verfügt DNP 3.0 über eine sehr mächtige Anwendungsschicht, die eine Dekodierung der Daten auch ohne Zuhilfenahme von impliziten Parametern erlaubt. DNP 3.0 verfügt über diverse Möglichkeiten zur Darstellung von Informationsobjekten und bietet auf der Anwendungsschicht einen hohen Grad an Interoperabilität. Dies wird durch eine gesteigerte Komplexität erkauft, was bei der Implementierung nicht gerade hilfreich ist und einen hohen Implementierungs- und Testaufwand erfordert.

    Anders als bei IEC 60870-5-101 verfügt das Protokoll über eine Transportschicht, die eine fragmentierte Übertragung von größeren Datenmengen erlaubt. Dies kommt dem Protokoll bei der Kommunikation über  TCP/IP zugute, da die gesamte Bandbreite des Netzwerks effektiv ausgenutzt werden kann.

    Auch ein Vorteil gegenüber IEC 60870-5-101 ist die Möglichkeit, auf der Anwendungsschicht eine Empfangsquittung von der Gegenseite anzufordern. Dadurch kann eine Unterstationen die Daten aus dem Puffer in Abhängigkeit davon entfernen, ob diese tatsächlich am Ziel angekommen sind und quittiert wurden. Diese Funktion erleichtert insbesondere den Einsatz von einfachen Routern.

    Die Sicherungsschicht wurde wie bei IEC 60870-5-101 an die Normen IEC 60870-5-1 und IEC 60870-5-2 angelehnt. Allerdings wurde lediglich das symmetrische Übertragungsverfahren (balanced mode) verwendet, das nur für vollduplex Punkt-zu-Punkt Verbindungen gedacht war. Da DNP 3.0 auch für halbduplex Partyline-Verbindungen eingesetzt wird,  existiert ein Mechanismus  zur Kollisionsvermeidung. Da dieser bestimmte Funktionen der Datenübertragungseinrichtungen voraussetzt, die nicht immer vorhanden sind, und eine exakte Konfiguration des Timings erfordert, ist der Einsatz in der Praxis oft problematisch. Durch dieses Manko wird in viele Fällen die Sicherungsschicht quasi außer Kraft gesetzt und  nur der unbestätigte Dienst (SEND/NO REPLY) in Verbindung mit gepollter Datenübertragung der Anwendungsschicht verwendet. Durch  Verwendung von TCP/IP als Kommunikationsmedium wird diese Problematik vermieden, da hier keine Kollisionen auftreten können bzw. vom Netzwerk bereits abgefangen werden.

    Zur Sicherstellung der Interoperabilität zwischen  verschiedenen Geräten, existieren zwei Formulare, die von jedem Hersteller ausgefüllt werden müssen:

    • DNP Device Profile
      definiert die grundsätzlichen Protokollfunktionen, die ein Gerät unterstützt
    • DNP Implementation Table
      definiert die Informationsobjekte und ihre Darstellung, die ein Gerät unterstützt

    Zusätzlich werden Untermengen des vollständigen Funktionsumfangs definiert und in drei Ebenen (Level) eingeteilt. Dies sind:

    • DNP Level 1
      ist die kleinste Untermenge und definiert nur die einfachsten Funktionen und Informationsobjekte. Die Ebene ist besonders gut geeignet für Kleinstgeräte (IEDs)
    • DNP Level 2
      ist gedacht für größere Geräte wie RTUs
    • DNP Level 3
      eignet sich für große RTUs und verfügt über fast den kompletten Funktionsumfang von DNP 3.0

    Die Ebenen sind abwärtskompatibel. D. h. ein Master, der Level 2 beherrscht, unterstützt Slaves der Ebenen 1 und 2.

    Jedes Gerät muss im "Device Profile" ausweisen, welche Ebene es unterstützt. Um die Kompatibilität sicherzustellen wurden im Jahr 2000 Kompatibilitätstests (Certification Procedure) entwickelt, allerdings bislang nur für Level 1 & 2. Hier wird schrittweise detailliert beschrieben, wie sich das Gerät in konkreten Fällen zu verhalten hat.

ISO/OSI Modell
7 Anwendungsschicht DNP V3.0 Data Object Library
DNP V3.0 Application Layer
6 Darstellungsschicht N/A
5 Sitzungsschicht N/A
4 Transportschicht DNP V3.0 Transport FunctionsDNP V3.0 Transport Functions
DNP V3.00 Data Link Layer
TCP, UDP
3 Vermittlungsschicht IP
2 Sicherungsschicht DNP V3.00 Data Link Layer
IEC 60870-5-2 (balanced)
IEC 60870-5-1 (FT 3)
IP
1 Bitübertragungsschicht RS232 (V.24)Ethernet (IEEE 802.3)
Verfügbare Protokollstacks

DNP V3.00, Master

DNP V3.00, Slave

Geeignete Produkte
  • ipConvLite
    ipConvLite

    Universeller Protokollkonverter für kleine und dezentrale Anwendungen

  • ipConvOPC
    ipConvOPC

    Windows Softwarepaket zur universellen Konvertierung diverser Standardprotokolle

  • ipConv/VM
    ipConv/VM

    Universelle Protokollkonvertierung für VMware Workstation und VMware ESXi

  • ipConv/Cloud
    ipConv/Cloud

    Universelle Protokollkonvertierung für Cloud-Umgebungen und Linux-basierte Edge-Geräte

  • ipConvLite/MEC2PBS
    ipConvLite/MEC2PBS

    Protokollkonverter mit integrierter PROFIBUS-DP, Slave Schnittstelle

  • ipConvLite/MEC2PBM
    ipConvLite/MEC2PBM

    Protokollkonverter mit integrierter PROFIBUS-DP, Master Schnittstelle

  • ipConvLite/MEC2PNS
    ipConvLite/MEC2PNS

    Protokollkonverter mit integrierter PROFINET-IO, Slave Schnittstelle

  • ipConv
    ipConv

    Universeller Protokollkonverter für höchste Ansprüche an Flexiblität

  • ip4Cloud/SEC3PB
    ip4Cloud/SEC3PB

    Daten von PROFIBUS rückwirkungsfrei erfassen und an IT/Cloud/SCADA-Dienste übertragen

  • ip4Cloud/SEC3IO
    ip4Cloud/SEC3IO

    Digitale I/O-Zustände schalten und überwachen, um sie an IT/Cloud/SCADA-Dienste zu übermitteln

  • ipELB
    ipELB

    4-Port Ethernet Line Breaker mit relaisgesteuerten Ethernet-Ports und integriertem I/O-Modul

Referenzen
  • Projekt CFE
    Projekt CFE, Mexiko

    Produkte: ipConv
    Protokollstacks: Conitel-2020, Slave DNP V3.00, Slave DNP V3.00, Master Harris-5000/6000, Slave Recon, Slave Indactic 33/41, 2033, Slave Fuji, Slave XMAT, Master

  • BASSLINK HVDC Victoria / Tasmanien
    BASSLINK HVDC Victoria / Tasmanien, Australien

    Produkte: ipConv
    Protokollstacks: DNP V3.00, Slave Simatic TDC, Master

  • PLN Gambir
    PLN Gambir, Indonesien

    Produkte: ipConv
    Protokollstacks: DNP V3.00, Slave DNP V3.00, Master HN Z 66 S 11/15, T63, Slave HN Z 66 S 11/15, T63, Master

  • CFE
    CFE, Mexiko

    Produkte: ipConv
    Protokollstacks: Harris-5000/6000, Slave Fuji, Slave DNP V3.00, Master

  • FSC Tecali und Juile
    FSC Tecali und Juile, Mexiko

    Produkte: ipConv
    Protokollstacks: DNP V3.00, Slave Simadyn-D, Master

  • DUBAL21
    DUBAL21, Vereinigte Arabische Emirate

    Produkte: ipConvLite
    Protokollstacks: DNP V3.00, Slave Modbus TCP/IP, Master

  • Projekt Legnica
    Projekt Legnica, Polen

    Produkte: ipConv
    Protokollstacks: IEC 60870-5-101, Slave DNP V3.00, Master

  • PEMEX, Madero
    PEMEX, Madero, Mexiko

    Produkte: ipConv
    Protokollstacks: DNP V3.00, Slave Harris-5000/6000, Slave Modbus, Master