Datensätze und Report Control Blocks
Datensätze und Report Control Blocks werden für die spontane Kommunikation benötigt. Hierbei definiert der Datensatz welche Daten und der RCB wann diese Daten übertragen werden.
Datensätze
Ein Datensatz ist eine geordnete Sammlung an Objektreferenzen. Er enthält nicht die Datenobjekte an sich, sondern die Referenzen zu FCDs (Functional Constrained Data Objects) bzw. FCDAs (Functional Constrained Data Attributes). Diese Referenzen sind die Elemente des Datensatzes und legen fest, welche Daten im Report übertragen werden sollen. Die Datensatzelemente und ihre Reihenfolge müssen sowohl dem Server als auch dem Client bekannt sein. Ein Datensatz ist einem bestimmten logischen Knoten zugeordnet, kann aber Referenzen zu Datenobjekten und Attributen aus anderen logischen Knoten beinhalten.
Ein Datensatzelement mit Functional Constraint FCD bezieht sich auf ein Datenobjekt eines Gerätes und kann durch einen Datenpunkt in WinCC OA repräsentiert werden. Ein Datensatzelement mit Functional Constraint FCDA bezieht sich auf eine Tag-Adresse am Gerät und kann durch ein Datenpunktelement in WinCC OA repräsentiert werden .
Dynamische Datensätze
Ein dynamischer Datensatz ist ein benutzerdefinierter Datensatz der auf SCADA-Ebene erstellt wird. Folgende Informationen müssen definiert werden:
-
Der Datensatz-Typ (persistent oder nicht-persistent)
-
Wo der Datensatz angelegt wird (z.B.: ied1|Device1|LN12, siehe auch Datensätze)
-
Die Datensatzelemente
Der dynamische Datensatz wird auf das Gerät geschrieben sobald der damit konfigurierte RCB aktiviert wird. Momentan werden dynamische Datensätze nur von Siemens-Geräten unterstützt.
Persistente Datensätze
Persistente Datensätze sind für alle Clients sichtbar und bleiben am Gerät gespeichert, wenn die Kommunikation zwischen Client und Gerät unterbrochen wird.
Bearbeitet kann der Datensatz nur von jenem Client werden, der ihn erstellt hat. Andere Clients können ihn durch Browsen des Gerätes ihrer Konfiguration hinzufügen, allerdings erscheint er für sie als statisch.
Der Client, der einen persistenten Datensatz ertstellt hat, löscht diesen Datensatz vom Gerät, sobald kein RCB, der mit diesem Datensatz konfiguriert ist, mehr aktiv ist.
Nicht-persistente Datensätze
Konfiguration von Datensätzen
-
Wenn Zeitstempel und Qualität vom Gerät benötigt werden, müssen Datensatzelemente mit Functional Constraint FCD verwendet werden. In diesem Fall werden die Informationen, entsprechend der in WinCC OA üblichen Vorgehensweise, auf die dazugehörigen Attribute des _original-Configs in WinCC OA geschrieben.
-
Datensatzelemente mit Functional Constraint FCDA sollten nur verwendet werden um Werte abzufragen, welche diese Informationen nicht zur Verfügung stellen, z.B. zur Abfrage von Konfigurationsinformationen.
-
Datensatzelemente mit Functional Constraint FCDA können verwendet werden, wenn Zeitstempel und Qualität eines Datenwerts als Originalwerte benötigt werden. In diesem Fall muss aber beachtet werden, dass diese Informationen in WinCC OA nicht mit dem tatsächlichen Prozesswert, zu dem sie gehören, verlinkt sind.
Beachten Sie, dass in einem Datensatz entweder nur FCD- oder nur FCDA-Datensatzelemente definiert werden dürfen.
Bei Verwendung des XML-Attributs ldName dürfen
Datensatzelemente nur Datenobjekte (DOs) des Logical Devices (LD) enthalten, in
dem der Datensatz definiert wurde.
Report control blocks
Der IEC 61850 Standard definiert einen Reporting-Mechanismus, welcher spontane Datenübertragung verwendet. Das führt zu einer Verringerung der Netzwerklast. Die Erstellung und Übertragung von Reports wird von Report Control Blocks gesteuert. Ein Report Control Block wird durch seine Attribute definiert, da sind unter anderem der zugewiesener Datensatz, Triggeroptionen und optionale Felder.
Die Art der Datenübertragung hängt von den konfigurierten Triggeroptionen ab:
-
Übertragung von Daten in regelmäßigen Intervallen
-
Eventbasierte Übertragung von Daten
-
General Interrogation (Generalabfrage, Daten von allen Datensatzelementen eines RCBs abrufen)
Der zugewiesene Datensatz definiert, welche Daten übertragen werden.
Mittels der optionalen Felder können zusätzliche Informationen übertragen werden.
RCB-Typen
Es gibt zwei verschiedene Typen von Report Control Blocks:
Unbuffered Report Control Block (URCB)
Informationen werden gemäß der gewählten Triggeroptionen übertragen. Im Fall eines Verbindungsverlusts wird die Übertragung unterbrochen, Informationen werden nicht gespeichert. Die Übertragung von Informationen wird erneut gestartet, nachdem die Verbindung wieder aufgebaut wurde. Informationen, die während des Verbindungsausfalls angefallen sind, gehen verloren.
Buffered Report Control Block (BRCB)
Informationen werden gemäß der gewählten Triggeroptionen übertragen. Im Fall eines Verbindungsverlusts werden die Informationen in einem Ringpuffer gespeichert. Die Größe des Puffers wird vom Gerätehersteller festgelegt. Sobald die Verbindung wiederhergestellt ist, wird die gepufferte Information in chronologischer Reihenfolge übertragen (sequence-of-event Funktionalität)
Ringpuffer:
Pufferverhalten eines BRCB:
1.) Im Falle eines Verbindungsverlusts wird die Entry ID des zuletzt übertragenen Reports gespeichert (in WinCC OA wird die Entry ID auf das interne DPE _IEC61850_RCB.RCBInfo.EntryID geschrieben). Das interne Datenpunktelement _IEC61850_IED.Config.ReadCompleteBuffer definiert bei Verbindungswiederherstellung, ob der gesamte Puffer oder nur die Reports die während dem Verbindungsverlust gepuffert wurden, abgefragt werden sollen.
In diesem Beispiel werden die Reports R3 bis R18 während dem Verbindungsverlust in den Puffer geschrieben und können nach Wiederherstellung der Verbindung abgefragt werden.
2.) Wenn während des Verbindungsausfalls zu viele Reports gepuffert werden, so dass der zuletzt übermittelte Report nicht mehr im Puffer gespeichert ist, kommt es beim Wiederherstellen der Verbindung zu einem Pufferüberlauf (Buffer Overflow).
Der zuletzt übermittelte Report ist in diesem Beispiel R2 und befindet sich nicht mehr im Puffer. Die Reports R3 bis R17 werden ebenfalls überschrieben und gehen durch den Verbindungsausfall verloren. Nach Wiederherstellung der Verbindung können die Reports R18 - R37 vom Puffer abgefragt werden.
Bei Verwendung von BRCBs in einem redundanten WinCC OA-System und einer Verbindung die "Passiver Host
verbindet sich zum Gerät" aktiviert hat, muss der Config-Eintrag
[iec61850] rcbReleaseTimeout auf einen
Wert gesetzt werden, der höher ist, als die höchste konfigurierte
resvTms.
Indizierte Report Control Blocks
Ein Report Control Block kann in einer normgerechten Konfigurationsdatei (SCD,
CID) als indiziert definiert werden. In diesem Fall sind am Gerät mehrere Instanzen
dieses RCBs verfügbar. Die Anzahl der Instanzen (1 - 99) wird über das XML-Attribut
RptEnabled festgelegt.
Beispiel
<ReportControl name="indexedRcb">
<RptEnabled max="3">
</ReportControl>Folgende RCBs sind am Gerät verfügbar:
- indexedRcb01
- indexedRcb02
- indexedRcb03
In WinCC OA wird der RCB als indexedRcb konfiguriert. Wird dieser RCB aktiviert, sucht der IEC 61850 Client automatisch eine freie Instanz. Die Suche beginnt bei der höchsten Instanz (im Beispiel 03). Ist keine Instanz verfügbar, gilt der RCB als temporarily-unavailable.
Das RCB Management Panel bietet die Möglichkeit, explizit eine Instanz, z.B. indexedRcb02 zu konfigurieren. Diese Instanz wird dann wie ein nicht indizierte RCB behandelt.
Verhalten bei Verbindungsverlust
Gilt für alle Adressen des Datensatzes, der diesem RCB zugeordnet ist.
Der Config-Eintrag setInvalidForConnLoss setzt Werte bei Verbindungsverlust ungültig. Durch Setzen dieses Config-Eintrags auf 0 kann das verhindert werden. Im Fall von spontaner Kommunikation muss der Default-Wert 2 verwendet werden. Folgende Fälle können auftreten, wenn die Bits per GI nach Wiederherstellung der Verbindung zurückgesetzt werden:
1. Der Server (IED) unterstützt das optionale Attribut "Reason For Inclusion"
-
Das Datenpunktelement bildet ein Attribut ab, für welches "t" verfügbar ist. Das GI-Bit wird gesetzt, der Zeitstempel bleibt unverändert.
-
Das Datenpunktelement bildet ein Attribut ab, für welches "t" NICHT verfügbar ist. Das GI-Bit wird NICHT gesetzt und der Zeitstempel wird auf den Zeitstempel des erhaltenen Reports gesetzt.
2. Der Server (IED) unterstützt das optionale Attribut "Reason For Inclusion" nicht: Das GI-Bit wird NICHT gesetzt. In manchen Fällen wird der Wert mit einem ungültigen Zeitstempel abgebildet.
Verhalten bei Kommunikationsverlust
Gilt für alle Adressen des Datensatzes, der diesem RCB zugeordnet ist.
- Im Fehlerfall, z.B. temporarily-unavailable, wird das "_invalid"-Bit gesetzt.
- Wenn der RCB aus einem anderen Grund nicht aktiv ist, z.B. vom Benutzer deaktiviert wurde, wird das "_out_of_service"-Bit gesetzt.
Zusätzlich kann ein RCB so konfiguriert werden, dass definierte User Bits gesetzt
werden, sobald der RCB nicht aktiv ist. Hierfür müssen die Config-Einträge
[iec61850] userBitUnsolDataUnavailable oder
[iec61850] userByteQualityMode verwendet werden.
Wurde einer dieser Config-Einträge gesetzt, markiert der RCB für alle Adressen seines Datensatzes folgende User Bits, sobald er nicht aktiv ist:
- userByteQualityMode ist gesetzt: Bit 7 dieses Bytes wird gesetzt.
- userBitUnsolDataUnavailable ist gesetzt: das entsprechende Bit wird gesetzt.
Wenn beide Einträge gesetzt wurden, wird der Eintrag [iec61850] userByteQualityMode gegenüber dem Eintrag
[iec61850] userBitUnsolDataUnavailable bevorzugt.
Wird ein RCB einem WinCC OA Projekt hinzugefügt, werden diese User Bits, sowie das "_out_of_service"-Bit für alle Adressen des dem RCB zugeordneten Datensatzes gesetzt, die bereits in WinCC OA konfiguriert sind. Adressen dieses Datensatzes, die nachträglich konfiguriert werden, werden markiert, sobald eine entsprechende Zustandsänderung des RCBs stattfindet.
