Details zum IEC Treiber

Typkennung = Art

Das Oktett der Typkennung legt Struktur, Typ und Format des folgenden Informationsobjekts fest.

Typkennung UI[1...8]<1..255>

<1..127>: kompatibler Bereich für Normfestlegungen

<128..135>: reserviert für Wegevermittlung von Nachrichten ("privater" Bereich)

<136..255>: für besondere Anwendungen ("privater" Bereich)

Welche Typkennungen in WinCC OA im Detail verwendet werden, entnehmen Sie dem Kapitel Kompatibilität.

Variable Strukturkennung

Die variable Strukturkennung enthält die Anzahl der Informationsobjekte oder -elemente und das SQ bit ("Single"/"Sequence"), das über die Adressierungsart der nachfolgenden Informationsobjekte oder -elemente informiert.

Oktett der Strukturkennung:

• Anzahl: UI7[1..7]<0..127>: 0 bedeutet es ist kein Informationsobjekt enthalten, <1..127> die Anzahl der Informationsobjekte.

• SQ: BS1[8]<0..1> Einzel/Folge

  <0>: Adressierung eines individuellen Elements oder einer Kombination von Elementen aus einer Anzahl von Informationsobjekten gleichen Typs

  <1>: Adressierung einer Folge von Informationselementen in einem einzelnen Objekt einer ASDU.

  SQ<0> und N<0..127>: Anzahl der Informationsobjekte

  SQ<1> und N<0..127>: Anzahl der Informationselemente in einem einzelnen Objekt einer ASDU

Die variable Strukturkennung wird vom Treiber gesetzt bzw. interpretiert. Das bedeutet, dass sie nicht parametriert werden muss und ist somit für den Anwender irrelevant.

Übertragungsursache (COT)

Die Übertragungsursache (spontan, periodisch etc.) leitet die ASDU zur Weiterbearbeitung an eine bestimme Anwendungsaufgabe (Programm). Das Oktett enthält Ursache, Bestätigung des Auftrages (positiv, negativ), ein Testbit (zur Prüfung der Übertragung ohne den Prozess zu beeinflussen) und die Herkunftsadresse:

• Ursache: UI6 [1..6]<0..63>; 0 nicht definiert, <1..63> Kennung der Ursache, <1..47> für den kompatiblen Bereich (gemäß der Norm), <48..63> privater Bereich für den besonderen Gebrauch

• P/N: BS[7]<0..1>; 0 positive Bestätigung, 1 negative Bestätigung

• T: BS[8]<0..1>; 0 keine Prüfung, 1 Prüfung

• Herkunftsadresse: UI8[9..16]><0..255>; <0> nicht festgelegt, <1..255> Nummer der Herkunftsadresse

Die Definition für den kompatiblen Bereich entnehmen Sie dem Kapitel Kompatibilität. Weitere Details zu den Übertragungsursachen entnehmen Sie der Norm.

Die Übertragungsursache wird entweder vom Treiber automatisch definiert oder kann vom Anwender vorgegeben werden. Das automatische Verhalten wird wie folgt implementiert:

Bei Kommandos (C_* Telegramme), die der Treiber schickt, wird eine Übertragungsursache 6 (Aktivierung) eingesetzt. Wenn der Treiber Meldungen (M_* Telegramme) schickt, so ist die Übertragungsursache 3 (Spontan).

Die eingangsseitige Abbildung der Übertragungsursache ist folgendermaßen implementiert:

20 <= COT <= 36 ... Meldung aufgrund einer GA (GA Bit im PARA Panel ist gesetzt).

COT == 5 ... Meldung aufgrund einer Einzelabfrage (EA Bit im PARA Panel ist gesetzt).

andere COT ... Meldung spontan oder andere Ursache (kein Bit gesetzt).

Um zu unterscheiden, ob Meldungen (M_* Telegramme) normal von WinCC OA gesendet werden (d.h. Übertragungsursache spontan = 3) oder als Folge einer IGQ (Inverse General Query), gibt es den Config-Eintrag useCOTGQ (siehe auch Mögliche Config-Einträge des IEC Treibers). Wenn Wert des Config-Eintrags "Yes" ist (Default ist "No"), dann wird als COT (= Cause of Transmission) bei allen Meldungen, die aufgrund einer IGQ gesendet werden die Übertragungsursache 20 (abgefragt durch GA), bei Zählermeldungen 37 (abgefragt durch allgemeine Zählerabfrage) eingesetzt. Im Normalfall ist die Übertragungsursache 3.

Für die manuelle Abbildung der COT gibt es zwei Möglichkeiten:

Die Verwendung von Userbytes

Die Verwendung einer COT Adresse hat den Nachteil eines zusätzlich notwendigen DPEs inklusive spezieller COT Peripherieadresse (siehe Addresstyp in Panel zur Definition der Peripherieadresse).

Die COT Adresse

Ab WinCC OA Version 3.8 gibt es die Möglichkeit die "Cause Of Transmission" (COT) auf Userbytes abzubilden. Diese Methode sollte in Zukunft gegenüber der COT Adresse bevorzugt werden.

Um die COT und auch die Herkunftsadresse eingangsseitig auf WinCC OA abzubilden, müssen die Config Einträge UserByteCOT und UserByteOrigin auf die Nummer des zu verwendenden Userbytes gesetzt werden. Standardmäßig ist der Wert 0 und es erfolgt keine Abbildung. Mit den folgenden Config Einträgen wird die COT auf das Userbyte 3 und die Herkunftsadresse auf Userbyte 4 abgebildet.

UserByteCOT = 3

UserByteOrigin = 4

Damit Werte von Userbytes ausgangsseitig in das Telegramm eingebaut werden, sind die Config Einträge ConnUserByteCOT und ConnUserByteOrigin auf die Nummer des zu verwendenden Userbytes zu setzen. Es gilt wie bei der Abbildung der Quality mittels ConnUserByteQ, dass jede Änderungen des entsprechenden Userbytes (oder eines darin enthaltenen Userbit)s einen Hotlink auslöst und damit auch der Wert an die Peripherie verschickt wird. Um mehrfache Telegramme zu vermeiden, muss in einer Anwendung der _original.._value und das entsprechende _original.._userbyte<x> in einem dpSet() gesetzt werden. D.h. wenn z.B. der Wert, COT und die Herkunftsadresse im gleichem Moment geändert werden sollen, muss das in einem dpSet() geschehen, um Telegramme mit unerwünschten Zwischenzuständen zu vermeiden.

Kompatibilität COT Adressen Userbyte-Variante

Eingangsseitig:

Bisher war es möglich für die COT und Herkunftsadresse eine „COT Peripherieadresse“ zu parametrieren. Dies funktioniert weiterhin, auch wenn UserByteCOT bzw. UserByteOrigin ungleich 0 sind. Allerdings ist es nicht sinnvoll in einem neuen Projekt die Verfahren zu vermischen.

Ausgangsseitig:

Auch ausgangsseitig gab es bisher „COT Peripherieadressen“. Diese Adressen funktionieren nur noch, wenn ConnUserByteCOT und ConnUserByteOrigin auf 0 gesetzt sind. Ist ein Eintrag davon ungleich 0, so werden nur die Informationen aus den „user bytes“ in das Telegramm eingebaut.

Ist das Userbyte für die COT auf 0 gesetzt, so wird die Default COT vom Treiber verwenden.

Gemeinsame Adresse der ASDU = Region, Komponente

Die gemeinsame Adresse wird für alle Objekte innerhalb einer ASDU gemeinsam genutzt. Die globale Adresse ist eine an alle Stationen eines bestimmten Systems gerichtete Adresse.

Gemeinsame Adresse: UI8[1..16]<0...65535>

<0>: nicht benutzt

<1...65534>: Stationsadresse

<65535>: globale Adresse

ASDU mit einer "Adresse an alle" in Steuerungsrichtung müssen in Überwachungsrichtung mit ASDU beantwortet werden, welche die spezifisch festgelegte gemeinsame Adresse (Stationsadresse) enthalten.

Informationsobjekte = Information Object Address

Die Adresse des Informationsobjektes (1, 2 oder 3 Oktette) wird als Zieladresse in Steuerungsrichtung und als Quelladresse in Überwachungsrichtung benutzt. Je nach Zahl der Oktette ist die Adresse der Informationsobjekte:

UI [1...8]<1...255>: HB

UI [1-16]<1...65535>: MB

UI [1-24]<1...16777215>: LB

Einer detaillierte Beschreibung entnehmen Sie der Norm IEC 60870-5-104.

Anzahl an Ports und Wiederaufbau der Verbindung

Die theoretische Anzahl der Ports (seriellen Schnittstellen), die mit einem IEC 101 Treiber behandelt werden können, hängt von der Anzahl der möglichen seriellen Schnittstellen des betreffenden Betriebssystem zusammen. Für Windows ist die Anzahl auf 255 limitiert.

Die theoretische Anzahl der Slaves im unsymmetrischen Betrieb ist durch den maximalen Wert der Linkadresse vorgegeben.

Die Angaben sind deshalb "theoretisch“, da meistens aus Performance- oder anderen Gründen die maximale Anzahl nicht sinnvoll ist.

Im Falle einer unterbrochenen Verbindung zur Peripherie, versucht der Treiber periodisch die Verbindung zur Peripherie wiederherzustellen.

Generalabfrage

Automatische Generalabfrage beim Treiberstart bzw. bei Redundanzumschaltung IEC

Die Eigenschaften der automatischen Generalabfrage können mit dem Config Eintrag autoGQ bestimmt werden (Details siehe im Kapitel Mögliche Config-Einträge des IEC Treibers). Der 104 Treiber und der 101 Treiber verhalten sich bezüglich automatischer Generalabfrage identisch. Für die Funktion der Generalabfrage ist es notwendig, dass die Common Objekt-Adressen in der Lokalen/Globalen Liste explizit definiert sind, d.h. keine Wildcards vorhanden sind.

Zugriff auf verschiedene Telegrammtypen mittels Subindex

Die unten nachfolgende Tabelle enthält die Informationen, wie bei den unterschiedlichen Telegrammtypen mittels Subindex auf die, im Telegramm vorhandenen Felder zugegriffen werden kann. Dabei sind noch folgende Punkte zu beachten:

Quality Information

In Befehlsrichtung (sowohl C_* als auch M_* Telegrammtypen können in Befehlsrichtung geschickt werden) wird die Quality Information bei manchen Telegrammen als ODER-Verknüpfung des über Subindex angegebenen Wertes mit dem Wert aus der Adresse gebildet (z.B. M_SP_NA_1 oder C_SC_NA_1). Das ist in der Regel dann der Fall, wenn die Daten, oder ein Teil der Daten) und die Quality Information im selben Byte enthalten sind). Bei den anderen Telegrammen kann der Wert nur über die Quality Information aus der Adresse gebildet werden (z.B. M_BO_NA_1 oder C_SE_NA_1).

Wenn die Qualitätsinformation eingangseitig auf Userbits abgebildet wird, so werden die Userbits bei allen betroffenen Subindizes gesetzt.

DPE Typ

Der DPE Typ ist nicht notwendigerweise so wie in der Tabelle angegeben zu setzen, da auch eine Typkonvertierung stattfindet. So kann z.B. statt eines bool Typs auch ein int verwendet werden, der dann die Werte 0 oder 1 annimmt. Bei inkompatiblen Typen gibt es eine Fehlermeldung während der Transformation. Sinnvollerweise sollte man aber, wenn es keine anderen Gründe gibt, die Typen der Tabelle verwenden.

Spezielle Subindizes

Für manche Telegrammtypen gibt es spezielle Subindizes, die den Zugriff auf die Daten erleichtern. So ist es z.B. beim M_DP_NA_1 Telegramm möglich mit dem Subindex 8 auf das DPI Feld als "unsigned int zuzugreifen. D.h. man braucht nicht zwei DPEs für DPI bit 0 und DPI bit 1 zu definieren.

Private Telegrammtypen

Der Telegrammtyp 135 gehört zu den privaten Typen. D.h. es wird der Inhalt eines BLOB DPEs übertragen und es findet keine Interpretation der Daten statt. Das gilt für den IEC 101 und 104 Treiber.

Dieser Telegrammtyp funktioniert daher nur bei DPEs vom Typ blob. Zusätzlich muss die Information Object Address auf 0.0.135 gesetzt werden.

Konsistenzprüfungen der Telegramme

IEC 101

Geprüft wird:

1. Konsistenter Telegrammkopf

2. Prüfsumme

Bei Fehler ist die Konsequenz der Wiederaufbau der Verbindung.

IEC 104

Geprüft wird:

1. Konsistenter Telegrammkopf

Bei Fehler ist die Konsequenz der Wiederaufbau der Verbindung.

Optimierung vom Datendurchsatz

Nach Möglichkeit werden Telegramme beim Versenden in ein Telegramm gepackt.

Es wird geprüft ob TYP, COT (= Cause of Transmission) und COA (Common Object Address) vom letzten Telegramm in der Queue mit dem aktuellen Telegramm übereinstimmen. Wenn ja, wird das Informationobjekt an das letzte Telegramm in der Queue angehängt, wenn das von der Länge her möglich ist. Es wird nur versucht das IOA an das letzte Telegramm in der Queue anzuhängen damit sicher gestellt ist, dass kein Telegramm ein anderes überholt.

Mögliche Fehlermeldungen bei der Verwendung vom IEC-Treiber

WCCOAiec (1), 2005.02.26 17:27:25.622, PARAM,SEVERE, 54, Unexpected

state, IecResources, DP-Element does not exist , _Iec_1.FileTransfer.Command:_original.._value

WCCOAiec (1), 2005.02.26 17:27:25.623, PARAM,SEVERE, 54, Unexpected state, IecResources, DP-Element does not exist , _Iec_1.FileTransfer.Status:_original.._value

Diese Meldungen deuten daraufhin, dass eine Inkonsistenz zwischen der Treiber-Version und den internen Datenpunkten bzw. deren Typen besteht.

WCCOAiec (1), 2005.02.27 16:27:19.990, PARAM,WARNING, 54, Unexpected state, IecTgLayer, generalQuery, Check format of local/global list entry, COA not correctly specified *.*.*.*.*

In der globalen/lokalen IEC-Liste ist *.*.*.*.* definiert. Die Log-Meldung ist eine Warnung, eine GA über den internen Datenpunkt bzw. den Config-Eintrag autoGQ > 0 ist damit nicht möglich. Damit dies möglich ist müssen die beiden ersten Einträge (Region + Komponente) ungleich "*" sein.