Genormte Kommunikation zwischen Windkraftanlagen

Transkript

1 Genormte Kommunikation zwischen Windkraftanlagen Weltweit werden vermehrt Windkraftanlagen sowohl Onshore als auch Offshore installiert; die meisten sind in Windparks organisiert. Um die Kommunikation in solchen Windparks mit Windkraftanlagen unterschiedlicher Hersteller realisieren zu können, gibt es den Kommunikationsstandard IEC Dieser basiert auf der IEC und wird ab Mitte 2009 als SPS-Bibliothek im Rahmen der Twincat-Supplement-Produkte verfügbar sein. Josef Papenfort Pascal Dresselhaus Datenmodelle sind hierarchisch aufgebaut. Die Objekte sind selbstbeschreibend, d. h. die Struktur der Objekte wird mit dem Telegramm übertragen. Neben der MMS- und TCP-Kommunikation bietet die Norm auch einen schnellen Der Markt mit Windenergieanlagen boomt und entsprechend groß ist auch die Konkurrenz unter den Anbietern. So kommt es nicht selten vor, dass in einem Windpark Windenergieanlagen (WEA) unterschiedlicher Hersteller betrieben werden. Zur notwendigen Kommunikation zwischen den WEA und der Leit - station setzte man bisher häufig proprietäre Protokolle ein, was jedoch einen hohen Aufwand für die Anpassungen auf beiden Seiten nach sich zog. Um diese Kosten zu minimieren, haben sich WEA- Hersteller und -Betreiber an einen Tisch gesetzt und in jahrelanger Abstimmungsarbeit die Norm IEC [1] beschrieben, die die Kommunikation zur Überwachung und Steuerung von Windenergieanlagen regelt. Obwohl die Kommunikation einfach ist, lassen sich auch komplexe Vorgänge mit diesem Protokoll realisieren. Der objektorientierte Ansatz Dr.-Ing. Josef Papenfort ist Produktmanger für Twincat bei der Beckhoff Automation GmbH in Verl. j.papenfort@beckhoff.com Dipl.-Ing. Pascal Dresselhaus ist bei der Beckhoff Automation GmbH in Verl in der Grundlagensoftware-Entwicklung tätig. p.dresselhaus@beckhoff.com Bild 1. Der neue Kommunikationsstandard für Windkraftanlagen wird als SPS-Bibliothek für Twincat zur Verfügung stehen vereinfacht die Konfiguration, die Diag - nose und die Wartung für alle Beteiligten (Bild 1). Die IEC beruht auf der IEC [2], einem allgemeinen Über - tragungsprotokoll für die Schutz- und Leittechnik in elektrischen Schaltanlagen der Mittel- und Hochspannungstechnik (Stationsautomatisierung). Physikalisch basiert die Kommunikation auf Ethernet und TCP/IP (Transmission Control Protocol/Internet Protocol); zur Client-Server- Kommunikation wird MMS (Manu facturing Message Specification) genutzt. Die im Jahr 2004 veröffentlichte IEC ist objektorientiert und ihre Zugang zu Messdaten, die via Ethernet ausgetauscht werden. Anstelle der MMSkann man auch eine OPC-Schicht nutzen. Freiräume für hersteller - spezifische Implementierungen Die Protokolle der IEC [3], der Vorgängernorm der IEC 61850, kommen in vielen Bereichen der Fernwirktechnik zum Einsatz, zum Beispiel bei der Automatisierung von Tunneln und Straßen. Alle Protokolle werden schon seit vielen Jahren verwendet, bieten aber noch immer Freiräume für herstellerspezifische Implementierungen. Dies soll sich mit der Einführung der IEC ändern. 2 Heft 1/2009

2 IEC Wind-Power-Plants IEC Client-Server-Services (Weitere Kanälte wie z. B. Goose können implementiert werden) 7 ACSI Application Layer MMS 6 ASN.1/BER Presentation Layer CO TCP/IP Ethernet Glasfaser/Twister Pair Session Layer Transport Layer Network Layer Data Link Layer Physical Layer Bild 2. Kommunikationsstack nach IEC 61850/IEC Client request confirm Provider Bild 3. Prinzip der klassischen Server/ Client-Kommunikation Server indication response Da das Basisübertragungsprotokoll TCP/IP datenstromorientiert ist, werden in den Telegrammen keine Angaben über den Anfang, das Ende oder die Länge einer Nachricht gemacht. Diese Angaben sind für die Automatisierungstechnik jedoch wichtig, da dort, wie in den oberen Schichten des IEC Kommunikationsstacks, nachrichtenorientiert gearbeitet wird. Eine Möglichkeit, einzelne Nachrichten über einen TCP-Datenstrom zu versenden und zu empfangen, stellt die Request for Comments 1006 (RFC1006) dar. Diese in die Twincat-SPS eingebundene Protokollerweiterung, mit dem Titel ISO Transport Service on top of the TCP, setzt auf dem datenstromorientierten TCP-Protokoll auf und stellt Anwendungen eine nachrichtenorientierte Kommunikation zur Verfügung. Hierbei werden zusätzlich zu den TCP-Daten weitere Informationen zwischen den Teilnehmern übertragen, um bestimmte Dienste für den Anwender erbringen zu können (ISO-Dienste als Erweiterung zu TCP). Die Abstract Syntax Notation One (ASN.1) (Bild 2) ist eine Beschreibungssprache, mit der sich Daten und Informationen unabhängig von der Umgebung, in der sie konkret auftreten, beschreiben lassen. Die Basic Encoding Rules for ASN.1 (BER) liefern die nötige und eindeutige Kodierung der Daten. Bisher ist ASN.1 die einzige von der ISO standardisierte, abstrakte Syntax1. Spezielle Twincat-SPS-Bausteine übernehmen die Kodierung und Dekodierung der BER-Regeln, unabhängig vom IEC Protokoll. Der ISO-Standard 9506 [4] Manufac - turing Message Specification (MMS) definiert den objektorientierten Austausch von Daten. Das Anwendungsprotokoll (Application Layer) bildet unter anderem die Basis für das Übertragungsprotokoll der IEC MMS stellt den aufsetzenden Protokollen eine Vielzahl von Diensten zur herstellerunabhängigen Kommunikation zur Verfügung. Des Weiteren basiert MMS auf einem strikten Client-Server-Modell (Bild 3). Die für diese Kommunikation benötigten Dienste sind in der Regel bestätigte Dienste. Die Dienste, die in der IEC für den Austausch von Daten definiert sind, werden auf MMS-Dienste abgebildet, um so einen Zugang zum Kommunikationsstack zu bekommen. Damit die Norm unabhängig von dem MMS-Protokoll ist, erfolgt die Abbildung der Dienste über ein abstraktes Service-Interface. Diese ACSI- Schnittstelle (Abstract Communication Service Interface) erlaubt eine universelle Anbindung der Norm an die unterlagerten Protokolle. So könnte in Zukunft auch eine Anbindung über Webservices (OPC) möglich sein, ohne die Norm IEC dafür speziell anzupassen. Heft 1/2009 3

3 Pilotprojekt Alpha Ventus : Einsatz auf hoher See Die Twincat-SPS-Bibliotheken für die IEC Kommunikation werden erstmalig im deutschen Offshore-Windpark Alpha Ventus [5], der rund 45 km nördlich vor der Insel Borkum liegt, zum Einsatz kommen. Die Testphase mit den zuständigen Leitsystemherstellern ist positiv verlaufen und spricht für die von Beckhoff verfolgte Entwicklungsstrategie. Mit der Konstruktion, dem Bau, dem Betrieb und der Netzintegration des Forschungsprojekts Alpha Ventus sollen grundlegende Erfahrungen, im Hinblick auf die zukünftige kommerzielle Nutzung von Offshore-Windparks, gesammelt werden. Für 2008 war die Errichtung der südlichen Hälfte des Windparks mit sechs Windenergieanlagen vom Typ Multibrid M5000 und des Offshore-Umspannwerks geplant. Die M5000 ist eine 5-MW-Offshore-Anlage. Das Steuerungskonzept hat Multibrid [6] in enger Zusammenarbeit mit Beckhoff überarbeitet und auf eine einheitliche Plattform gestellt. Datenmodell mit fünf Hierarchieebenen Die IEC bildet die Basis für die IEC ; deshalb sind die Datenoder Objektmodelle für beide Normen identisch. Die IEC wurde lediglich um einige windkraftspezifische Informationen ergänzt. Standards für Brennstoffzellen und die dezentrale Energieversorgung sind geplant. Das Datenoder Objektmodell der Norm gliedert sich in fünf Hierarchieebenen: Server Logical Device Logical Node Data Object Data Attribute Der Server bietet den Anschlusspunkt eines Gerätes an das Kommunikationssystem. Er kann an mehreren Anschlussstellen implementiert werden und erlaubt somit einen redundanten Aufbau. Die zweite Hierarchieebene unterteilt ein einzelnes physikalisches Gerät in mehrere separate Teile, sogenannte Logical De - vices (Logische Geräte). Dadurch können zusammengehörige Funktionen, bzw. Objekte, aufgrund ihrer Gemeinsamkeiten zusammenstehen und beispielsweise gemeinsam in einen anderen Betriebsmodus geschaltet werden. Die dritte Hierarchiestufe bilden die Logical Nodes (Logische Knoten). Diese repräsentieren die Informationen aller erdenklichen Teilfunktionen, die in der digi talen Stationsleittechnik und unter anderem in Windkraftanlagen vorkommen können, wie Schutz- und Automatisierungsfunktionen sowie Funktionen zur Verarbeitung von Mess- und Zählwerten. Für alle genormten Logical Nodes der IEC und der IEC gibt es defi- Bild 4. Instanzen mehrerer Logical Nodes in einem Logical Device ST_LD_WEA 4 Heft 1/2009

4 Bild 5. Der Logical Node WROT mit mandatory und optional Data Objects nierte Bezeichnungen, die aus einem Kürzel aus vier Buchstaben bestehen. WTUR ist beispielsweise die Abkürzung des Logischen Knotens Wind turbine general information. Ein Logical Device kann aus mehreren solcher Knoten bestehen. Ein Logical Node besteht wiederum aus mehreren Data Objects (Datenobjekte), welche die vierte Hierarchieebene bilden. Diese hat die Besonderheit, dass die Datenobjekte ihrerseits hierarchisch verschachtelt sein können. Ein Datenobjekt kann somit aus mehreren Unterdatenobjekten bestehen, bevor letztendlich auf einen Datentyp zugegriffen wird. Diese sogenannten Data Attributes (Datenattribute) bilden die unterste Hierarchieebene und stellen Detailinformationen oder Werte der Datenobjekte dar. Da für viele Datenobjekte immer derselbe Umfang an Datenattributen definiert ist, werden die Attribute eines Objektes in den Common Data Classes (CDC) zusammengefasst. In den meisten Fällen sind Datenattribute elementare Datentypen, wie Boolean oder Integer. Es sind aber auch Strukturen und Arrays von elementaren Datentypen möglich. Um einen bestimmten Wert eines Servers lesen oder schreiben zu können, bedarf es einer Referenz (Pfad) auf diese Variable. Dabei werden die verschiedenen Hierarchiestufen bis hin zum Basistyp aneinandergehängt. Ein Beispiel dafür ist die Statusabfrage WEA/WTRF$Trf - OpTmRs$ manrs$stval, mit der eine Leitstation eine Windkraftanlage fragt, wie der Objektstatus des Knotens Wind turbine transformer information ist. Durch sogenannte Data Sets lassen sich mehrere solcher Referenzen zusammenfassen und durch Reporting-Funktionen, welche in der Norm als speichernd oder nicht speichernd definiert sind, gemeinsam übertragen. Somit entfällt ein einzelnes Aufrufen der Referenzen für Datenobjekte, die meistens im Kontext zueinander kommuniziert werden. Kommunikation in der SPS Der Kommunikationsstack wurde in der Twincat-SPS in Form von Bibliotheken realisiert: unter der Prämisse, dass möglichst jede Schicht des Open System Interconnection Reference Models (OSI- Modell) unabhängig, d. h. in einer eigenen Bibliothek, implementiert ist. In der Bibliothek TcIEC61850.lib sind alle in der Norm definierten Basisdatentypen hinterlegt. Darüber hinaus findet man dort das im Standard beschriebene Datenmodell; beim Zusammensetzen seiner Logical Devices kann der Anwender auf 91 vordefinierte Logical Nodes und 29 Common Data Classes zurückgreifen. Alle für das Auslesen der angelegten Datenstruktur notwendigen Services sind ebenfalls in dieser Bibliothek enthalten. In der Bibliothek TcIEC61400_25.lib sind alle windkraftspezifischen Knoten und Datenklassen implementiert und können in Verbindung mit der TcIEC61850.lib zur Kommunikation in Windparks eingesetzt werden. Die Gliederung in einzelne Bibliotheken sorgt für mehr Übersichtlichkeit und Modularität der Produkte. Schließlich handelt es sich um zwei verschiedene Standards, welche man jeweils als eine separate Implementierungsschicht betrachten Heft 1/2009 5

5 kann. Daher wird die konsequent unabhängige Bibliotheksentwicklung, wie sie bei dem OSI-Modell angewendet wurde, fortgesetzt. Die Konfiguration logischer Geräte verdeutlicht folgendes Beispiel: Es wird ein Logical Device mit dem Namen My- WEA (Instanz von: ST_LD_WEA) als Struktur in der Twincat-SPS angelegt. (Bild 4) In jedem logischen Gerät sind die Pflichtknoten LLN0 (Logical Node Zero) und LPHD (Logical Node Physical Device) einzubinden, wie in den beiden hier erwähnten Normteilen beschrieben. Darüber hinaus lassen sich alle für dieses Gerät spezifischen Knoten implementieren. In diesem Beispiel sind dies die Logical Nodes WGEN (Wind turbine generator information), WROT (Wind turbine rotor information), WTOW (Wind turbine tower information), WTRF (Wind turbine transformer information) und WTUR (Wind turbine general information). Sämtliche logischen Knoten müssen vom Anwender nur noch instanziiert werden, da sie bereits alle in den entsprechenden Bibliotheken zur Verfügung stehen. Eine Hierarchiestufe tiefer befinden sich die Datenobjekte der Knoten. Dabei unterscheidet die Norm, ob ein Datenobjekt zwingend (mandatory), unter bestimmten Umständen (conditional) oder eventuell (optional) in einem Logical Node ent halten sein muss. Wenn ein Kunde die Default-Datenobjekte kommunizieren möchte, reicht das Anlegen des Geräts MyWEA. Sollen optionale Datenobjekte nicht kommuniziert werden, so ist es möglich, diese auszukommentieren. Am Beispiel des Logical Node WROT lässt sich dieser Vorgang verdeutlichen (Bild 5). In diesem Fall werden die optionalen Datenobjekte für den Hydraulikdruck des Pitch-Systems nicht kommuniziert. Hoher Entwicklungsaufwand reduziert den Applikationsaufwand Der hohe Entwicklungsaufwand spiegelt sich in einem für den Kunden geringen Applikationsaufwand wider. Wenn der Nutzer alle seine Geräte konfiguriert hat, kann er die Kommunikation mit einem beliebigen Client, der die Standards der IEC und IEC unterstützt, starten. Dabei wird im Initialisierungsschritt zunächst die angelegte Datenstruktur des Servers geladen. Im Anschluss ist es beim Verbindungsaufbau mit dem Beckhoff-Server [4] möglich, eine Passwortabfrage durchzuführen. So kann man nichtautorisierten Clients den Verbindungswunsch verwehren. Dafür ist Bild 6. Authentifizierung der Clients im TwinCAT-Server lediglich die Passwortabfrage (baccess- Control) einzuschalten und der Autorisierungsmechanismus einzustellen (Bild 6). Mit dem Array AccessControl lassen sich mehrere Passwörter für verschiedene User festlegen. Hat der Server den Verbindungswunsch des Clients akzeptiert, kann dieser die noch unbekannte Datenstruktur des Servers auslesen. Der Austausch der mit den BER-Encoding-Rules kodierten Daten erfolgt über TCP/IP. Dafür bietet sich der Twincat-TCP/IP-Connection-Server an. Er ermöglicht die Realisierung eines oder mehrerer TCP/IP-Server/-Clients in der Twincat-SPS sowie die Implementierung eines Servers auf Basis von Windows- XP- und Windows-CE-Systemen. Die für den Datenaustausch verantwortlichen Kommunikationsdienste der IEC werden, wie beschrieben, auf MMS- Diens te abgebildet. Die wichtigsten sind dabei die Lese- und Schreibdienste. Um die im Abschnitt Datenmodell angesprochene Reporting-Funktion nutzen zu können, muss ein Anwender zunächst Data Sets (Datengruppen) erzeugen, die den Zugriff auf eine beliebige Anzahl von Datenobjekten, unter Verwendung eines einzigen Namens, erlauben. Dieser Name, bzw. die Referenz der Datengruppe an sich, ist lediglich eine einzelne Referenz auf mehrere spezifische Referenzen der Datenobjekte. Um eine solche Datengruppe zu erstellen, muss dem Funktionsbaustein die Anzahl FB_CreateDataSet unumberofref arrofref srefname bbusy berror UErrID Bild 7. Funktionsbaustein zum Erzeugen eines Data Sets der Objekte und deren Referenzen übergeben werden (Bild 7). Die Datengruppe erhält einen eindeutigen Namen, der einem Report-Block übergeben wird, welcher aufgrund eintretender Ereignisse die Übertragung der Datengruppe auslöst. Unter Ereignissen versteht man die Auswertung der sogenannten Trigger-Optionen. Dabei kann dem Report-Block mitgeteilt werden, auf welche Art von Ereignis er reagieren soll: Reagiert er auf ein Data Change, kommuniziert er das gesamte Data Set, sobald sich ein Wert innerhalb dieser Gruppe verändert hat. Praxis-Erfahrungen und Ausblick Während der ersten Entwicklungsphase des Servers boten Demo-Clients von verschiedenen Anbietern eine erste nützliche Testplattform. Dabei entwickelte das Entwicklungsteam ganz bewusst keinen eigenen Test-Client, um eventuelle Beckhoff-spezifische Lösungen zu unterbinden. So konnte man vom ersten Entwicklungsschritt an die Normkonformität des Servers testen und gewährleisten. Im Fokus der nächsten Entwicklungsschritte steht die weitere Verbesserung der Benutzerfreundlichkeit. Dabei sollen unter anderem Werkzeuge entwickelt werden, welche das Auskommentieren optionaler Datenobjekte in Common Data Classes ersetzen. Ebenso sollen - neben MMS - andere Protokolle, wie Webser - vices oder OPC eingebunden werden, um dem Kunden noch mehr Flexibilität zu bieten. Ein anderer Aspekt ist die Entwicklung des von der Norm verwendeten Goose-Kanals (Generic Object Oriented Substation Events). Er ist für den Austausch von hoch prioren Echtzeitdaten zuständig. Die Echtzeitkommunikation kann für Schutzauslösungen und -blockierungen benutzt werden und setzt direkt vom Protokoll auf die Ethernet- Technologie auf. Literatur [1] IEC : Wind turbines - Communications for monitoring and control of wind power plants. Genf/Schweiz: Bureau Central de la Comission Electrotechnique Internationale [2] IEC 61850: (VDE ) Communication networks and systems in substations. Genf/Schweiz: Bureau Central de la Comission Electrotechnique Internationale [3] IEC : Telecontrol equipment and systems. Genf/Schweiz: Bureau Central de la Comission Electrotechnique Internationale [4] Beckhoff Automation: [5] Alpha-Ventus-Projekt: [6] Multibrid: [7] Wind-Spezial PC-Control Heft 1/2009