Von der Simulation zur Realität: IEC 61499 konforme Re-

gelanwendungen für Solare Energiesysteme Marc Jakobi2, Tjarko Tjaden1, Volker Quaschning1, Urs Stöckli2, Luc Meier2

1HTW Berlin, 2Vela Solaris AG 1Wilhelminenhofstraße 75A, 12459 Berlin, Deutschland

2Stadthausstrasse 125, 8400 Winterthur, Schweiz

Tel.: +41552207154

E-Mail: marc.jakobi@velasolaris.com

Internet: 1www.pvspeicher.htw-berlin.de 2www.velasolaris.com

1 Einleitung

Abnehmende Einspeisevergütungen und die Kombination von steigenden Netzbe-

zugskosten und fallenden PV-Erzeugungskosten treiben den Trend für PV-Systeme

weiter in Richtung der Eigenversorgung. Immer mehr Anlagenbesitzer legen sich ei-

ne Batterie und/oder eine Wärmepumpe zu. Jedoch führen politische Rahmenbedin-

gungen, wie z. B. die Begrenzung der Netzeinspeisung, zum Bedarf nach immer

komplexeren, intelligenten Betriebsstrategien.

Heute existiert auf dem Markt eine große Auswahl an „Smart Energy Management”-

Lösungen. Deren Hauptaufgabe besteht meist darin, den Verbrauch durch progno-

sebasierten Betrieb von Batteriespeichern und/oder durch Demand Side Manage-

ment (DSM) in Zeiten hoher PV-Erzeugung zu verschieben. Die Entwicklung von sol-

chen Regelanwendungen ist oftmals ein langer und mühsamer Prozess. Zunächst

werden die Algorithmen in einer Prototypenphase mit Entwicklungsumgebungen wie

Matlab/Simulink® entworfen und simuliert, bevor sie dann in eine Programmierspra-

che, die von der Steuerungshardware verstanden werden kann, portiert werden

müssen. Proprietäre Anwendungen, die heute auf dem Markt existieren, sind teuer

und für den Installateur und Endanwender häufig intransparent in Bezug auf die ge-

naue Art der Regelung.

Für die Vermeidung von Abregelungsverlusten existiert mit dem PVprog Algorithmus

eine open source Lösung, welche an der HTW Berlin in Matlab® entwickelt wurde [1].

Um im Feld anwendbar zu sein, muss der Algorithmus jedoch in andere Program-

miersprachen portiert werden. In der PV-Industrie fehlt es an generischer, standard-

basierter Software zum Management von Multi-Erzeuger Energiesystemen.

2 Zielsetzung

Dieser Beitrag hat zum Ziel, durch open source Bibliotheken, welche

Co-Simulationen von IEC 61499 Regelanwendungen und Simulationstools ermögli-

chen, die Entwicklung von intelligenten Regelsystemen zu erleichtern. Mit einer Mi-

nimierung der Prototypenphase auf ein absolutes Minimum wird die Notwendigkeit,

Regelsoftware in andere Sprachen zu portieren, eliminiert. Mithilfe der

Co-Simulationstools werden open source Regelanwendungen, die auf einer breiten

Auswahl von SPS-Hardware (speicherprogrammierbare Steuerungshardware) an-

wendbar sind, entwickelt und validiert. Dabei besteht ein Fokus auf netzgekoppelte

PV-Systemkonfigurationen, wie in Abbildung 1 schematisch dargestellt. Jedes Sys-

tem beinhaltet einen PV Generator, eine elektrische Last und optional eine Batterie

und/oder eine Wärmepumpe. Der Regler steuert die PV-Inverter, die Batterie und die

Wärmepumpe an. Zusätzlich bezieht er Messwerte von allen Komponenten. Andere

Haushaltsgeräte wie Waschmaschinen und Geschirrspüler, die potenziell für DSM

genutzt werden könnten, werden im Rahmen dieses Beitrags nicht betrachtet. Aller-

dings sind die Regelanwendungen modular aufgebaut, sodass neue Komponenten

zu einem späteren Zeitpunkt hinzugefügt werden können. Die Zielsetzung lässt sich

wie folgt zusammenfassen:

• Erleichterung des Entwicklungsprozesses von Regelanwendungen durch Mi-

nimierung der Prototypenphase.

• Eliminierung der Notwendigkeit, Prototypen in andere Programmiersprachen

zu portieren.

• Entwurf und Validierung von generischen, standardbasierten, intelligenten o-

pen source Regelanwendungen.

Batterie

NetzLast

Wärme-pumpe

PV

Regler

Messung

Ansteuerung

Physikalische VerbindungOptionale Verbindung

Abbildung 1: Systemübersicht und Integration der SPS.

3 Technologieauswahl

Nachfolgend werden die Kriterien für die Regelanwendungen definiert. Unterschied-

liche Technologien werden verglichen und anhand der Kriterien ausgesucht.

3.1 Kriterien

Zu Beginn dieser Untersuchung war es unklar, ob der Aufbau eines Feldtests inner-

halb der vorgegebenen Zeit möglich sein würde. Aus diesem Grund ist Flexibilität ein

Hauptkriterium für die Regelanwendungen. Sie müssen so aufgebaut sein, dass ihre

Funktionalität mit den vorhandenen Tools validiert werden kann. Um die Prototypen-

phase zu minimieren, muss es des Weiteren möglich sein, die mithilfe von Simulati-

onstools entwickelten Anwendungen mit möglichst geringen Änderungen an der Re-

gellogik in realen Systemen einzusetzen. Wie in der Zielsetzung erwähnt, soll die

Software generisch und standardbasiert sein, um eine hohe Portabilität und einfache

Nachvollziehbarkeit für Nutzer und Entwickler zu gewährleisten. Schlussendlich soll

das Projekt komplett open source sein. Somit darf die Nutzbarkeit der Regelanwen-

dungen nicht durch proprietäre Soft- oder Hardware begrenzt werden.

3.2 Standard-Auswahl

Derzeit sind zwei Standards für SPS-Regelanwendungen definiert: IEC 61131-3 [2]

(von 1993) und IEC 61499 [3] (von 2005, in 2012 revidiert), wobei sich der erstere in

der Automatisierungsindustrie etabliert hat [4]. IEC 61131-3 definiert fünf Program-

miersprachen: Function Block Diagram (FBD), Instruction List (IL), Ladder Diagram

(LD), Sequential Function Chart (SFC) und Structured Text (ST). SPS-Anwendungen

können in Entwicklungsumgebungen wie CODESYS mit Kombinationen dieser grafi-

schen und textuellen Sprachen programmiert werden. Dass sich der Standard in der

Automatisierungsindustrie bereits etabliert hat, ist das Hauptargument für dessen

Verwendung. Es existiert eine große Nutzercommunity und eine Vielzahl an Soft-

wareumgebungen. Langfristig kann die prozedurale Herangehensweise jedoch nicht

den steigenden Anforderungen an SPS gerecht werden [5]. Des Weiteren existieren

in IEC 61131-3 keine Spezifikationen bezüglich der Kreuzkompatibilität zwischen

verschiedenen Hardware-Plattformen. Aus diesem Grund kann es dazu kommen,

dass Regelanwendungen bei Änderung der Hardware neu programmiert werden

müssen.

Um diese Nachteile anzugehen, wurde IEC 61499 ausgearbeitet. Dieser Standard

definiert eine graphische Programmiersprache, bestehend aus Funktionsblöcken

(FBs), ähnlich wie in FBD. FBs und die damit programmierten Regelanwendungen

werden im Extensible Markup Language (XML) Format gespeichert und sind dank

der „IEC 61499 compliance profile for feasibility demonstrations“ [6] (deutsch.:

„IEC 61499 Konformitätsprofil für Realisierbarkeitsdemonstrationen“) nicht an eine

bestimmte Hardware gebunden. Desweiteren sind die Anwendungen objekt- und

event-orientiert, was in einer erhöhten Modularität und der Möglichkeit von komple-

xen, verteilten Regelanwendungen resultiert. Der Nachteil des Standards besteht

darin, dass er bisher in der Industrie noch nicht vollständig etabliert wurde [5]. Die

Community ist verglichen mit IEC 61131-3 noch klein und es besteht eine ver-

gleichsweise geringe Auswahl an Software und Hardware. Langfristig soll jedoch

IEC 61131-3 revidiert und kompatibel mit IEC 61499 gemacht werden [8].

Die Vor- und Nachteile der beiden SPS-Standards sind in Tabelle 1 zusammenge-

fasst. Aufgrund der deutlich überwiegenden positiven Eigenschaften des IEC 61499

Standards wird dieser für die in diesem Beitrag entwickelten Regelanwendungen

ausgewählt. Als Entwicklungsumgebung wird die open source Software 4diac [8]

verwendet.

Tabelle 1: Vor- (+) und Nachteile (-) der SPS-Standards.

IEC 61131-3 IEC 61499

++ Erfahrung - Noch nicht in der Industrie etabliert

+ Große Community - Kleine Community

+ Große Auswahl an Soft-

ware/Hardware

o Wachsende Auswahl an Soft-

ware/Hardware

- - Geringe Flexibilität ++ Hohe Flexibilität

- - Plattformabhängig ++ Plattformunabhängig

- - Kaum bis keine Interoperabilität ++ Hohe Interoperabilität

- - Kaum bis keine Portabilität ++ Hohe Portabilität

- Für zentralisierte Systeme konzi-

piert

+ Für verteilte Systeme konzipiert

- - Nur einfache Regellogik möglich ++ Intelligente Regellogik möglich

- Geringe Zuverlässigkeit + Hohe Zuverlässigkeit

4 Software-Bibliotheken für die Co-Simulation von IEC 61499

Regelanwendungen mit Matlab und Polysun

Da die verwendete IEC 61499 konforme Entwicklungs- und Laufzeitumgebung 4diac

recht jung ist, sind die verfügbaren Test- und Validierungsmöglichkeiten noch recht

begrenzt. Um diese Limitierungen zu umgehen und um die Validierung von

IEC 61499 konformen Regelanwendungen durch Simulation zu ermöglichen, wurden

je eine Kommunikationsbibliothek in Matlab® und JAVA™ entwickelt. Beide Biblio-

theken basieren auf [6] und verwenden das „Transmission Control Protocol“

(TCP/IP) und/oder das „User Datagram Protocol“ (UDP/IP), um Daten zwischen den

Simulationsprogrammen und Regelanwendungen zu transportieren. Dabei werden

die IEC 61499 Datentypen (z. B. LREAL, REAL, INT, …) in entsprechende Matlab-

(double, single, int16, …) bzw. JAVA-Datentypen (double, float, int, …) konvertiert

und umgekehrt.

Für die Verwendung der Bibliotheken sind Kenntnisse in den jeweiligen Program-

miersprachen erforderlich. Aus diesem Grund wurde zwecks erhöhter Benutzer-

freundlichkeit die JAVA-Bibliothek in Polysun® [9] Plugin-Steuerungen eingebun-

den – je ein Aktor und ein Sensor für die Komponenten PV und Batterie, ein Aktor für

Wärmepumpen und ein Sensor für die elektrische Last. Für die Kommunikation zwi-

schen der Regelanwendung und den Plugin-Steuerungen wurde zusätzlich eine ent-

sprechende IEC 61499 Funktionsblock-Bibliothek konzipiert. Die Co-Simulation zwi-

schen der Regellogik und dem Polysun-Modell wird in Abbildung 2 qualitativ visuali-

siert. Durch den modularen Aufbau der Schnittstellen ist es für den Einsatz der Re-

gelanwendung in einem realen System lediglich notwendig, die Kommunikationslo-

gik, die bisher für die Verknüpfung mit Polysun konzipiert war, mit einer auf die jewei-

ligen Systemkomponenten zugeschnittenen Kommunikationslogik zu ersetzen. Der

Quellcode der Matlab- und JAVA-Bibliotheken sowie des Polysun-Plugins werden

auf dem Internet-Portal GitHub zur Verfügung gestellt.

Netzwerk

Polysun-

Simulationsmodell

IEC 61499

Regellogik

IEC 61499

Kommunikations-

Logik

Plugin

Abbildung 2: Visualisierung der Kommunikationsschnittstelle zwischen der Simulationssoftware Poly-sun und einer IEC 61499 Regelanwendung (qualitative Darstellung).

5 Implementierung und Co-Simulation der Regelanwendungen

Mittels Co-Simulation mit den im Zuge dieses Beitrags entwickelten Kommunikati-

onsschnittstellen wurden drei IEC 61499 Regelanwendungen konzipiert, welche je-

weils alleine oder in Koordination miteinander agieren können. Nachfolgend werden

diese beschrieben.

5.1 Eigenversorgungsoptimierung von SG Ready Wärmepumpen

Mit über 1000 Wärmepumpen, die mit dem „SG Ready“ Label zertifiziert sind [10],

hat sich die Schnittstelle in Deutschland als Standard durchgesetzt. Die Richtlinie

gibt vor, dass SG Ready zertifizierte Wärmepumpen eine Beeinflussung ihres Be-

triebs durch Ansteuerung von zwei Kontaktschaltern ermöglichen müssen. Dies re-

sultiert in vier Betriebszuständen, die in Tabelle 2 aufgelistet und beschrieben sind.

Bedauerlicherweise existiert derzeit keine fixe Definition der SG Ready Modi 3 und 4.

In der Regel schaltet die interne Regelung der Wärmepumpe bei unterschiedlichen

Temperaturschwellenwerten im Pufferspeicher und mit einer vorgegebenen Hystere-

se automatisch zurück in den Zustand 2. Aus Nutzersicht wäre es wünschenswert,

klar definierte Standardeinstellungen der Schaltzustände zu haben, z. B. fixe

Schwellenwerte sowie eine Klarstellung, ob ein Heizstab eingesetzt wird oder nicht.

Basierend auf Tjaden [11] wurde für diese Untersuchung anhand von Co-Simulation

mit Polysun eine Regelanwendung für SG Ready Wärmepumpen entwickelt, welche

deren Betrieb in Zeiten erhöhter PV-Überschüsse verschiebt, um die Eigenversor-

gung zu optimieren und den Netzbezug zu minimieren. Die Konditionen, bei denen

die Wärmepumpe von einem Betriebsmodus in den anderen wechselt, werden in

Abbildung 3 veranschaulicht. Die Regelanwendung verwendet den Schaltzustand 1

nicht.

Tabelle 2: Die vier Betriebszustände von SG Ready Wärmepumpen [12].

# Schaltzustand Kurzbeschreibung Erläuterung

1 1 : 0 Aus Die Wärmepumpe wird für maximal

2 h ausgeschaltet.

2 0 : 0 Normalbetrieb Der Betrieb wird durch eine interne

Regelung bestimmt.

3 0 : 1 Verstärkter Betrieb I Einschaltempfehlung. Eine interne

Regelung bestimmt, ob die Wärme-

pumpe tatsächlich eingeschaltet wird

oder nicht.

4 1 : 1 Verstärkter Betrieb II Definitiver Einschaltbefehl, sofern die

interne Regelung dies zulässt.

VERSTÄRKT II4

VERSTÄRKT I3

NORMAL2

PPV PV-LeistungPWP,nom Elektrische Nennleistung

der WärmepumpePgf Netzeinspeiseleistung

(PV-Überschüsse)Pload Elektrische Last

(inkl. Wärmepumpe)fon/off Ein/Ausschaltschwelle

(10 bis 150 %)df Abregelungsfaktor

(1 = keine Abregelung, 0 = volle Abregelung)

df < 1

Abbildung 3: Umschaltkonditionen der SG Ready Wärmepumpenregelung.

In der Simulation wird davon ausgegangen, dass die interne Regelung der Wärme-

pumpe im Betriebsmodus 3 bei einer Schwellentemperatur von 55 °C in der dritten

Schicht und einer Hysterese von 5 K in den Normalbetrieb umschaltet. Für den Be-

triebsmodus 4 ist der Schwellenwert auf 70 °C gesetzt. Die Regelanwendung ver-

wendet nach Empfehlung von Tjaden [11] für Systeme mit einem

PV-/Wärmepumpen Nennleistungsverhältnis von 3 : 1 eine Ein/Ausschaltschwelle

von 100 %. Abbildung 4 vergleicht für einen ausgewählten sonnigen Tag ein in Poly-

sun simuliertes PV-System mit Wärmepumpe zur Heizungs- und Trinkwarmwasser-

(TWW) Unterstützung ohne SG Ready Regelung (links) und mit Regelung (rechts).

Oben sind jeweils die Leistungsflüsse und unten die Temperaturen in den unter-

schiedlichen Schichten des TWW-Speichers für denselben Tag abgebildet. Ohne

Regelung springt die Wärmepumpe morgens einmal an und heizt den Speicher auf.

Im Laufe des Tages fallen die Temperaturen stufenweise, sodass die gespeicherte

Energie abends nicht mehr ausreicht, um den TWW-Wärmebedarf zu decken. Mit

der Regelung springt die Wärmepumpe aufgrund der hohen PV-Überschüsse je

einmal vormittags und nachmittags in den SG Ready Modus 3. Dadurch werden die

TWW-Speichertemperaturen auf einem höheren Niveau gehalten, was wiederum

dazu führt, dass der Speicher die TWW-Last am Abend decken kann und die Netz-

bezugsspitze gegen 18:00 Uhr eliminiert wird. In der Jahressimulation erhöht sich

der Autarkiegrad von 21,2 % auf 24,5 %, der Eigenverbrauchsanteil steigt von

22,3 % auf 26 % und Netzeinspeisung und Netzbezug verringern sich respektive um

364 kWh und 298 kWh. Diese Lastverschiebung entspricht in etwa dem monatlichen

Stromverbrauch der Wärmepumpe ohne SG Ready Regelung außerhalb der Heizpe-

riode. Durch eine Feineinstellung der Ein/Ausschaltschwelle, mit einem grösseren

TWW-Speicher und mit einem energieeffizienteren Gebäude [13] würden die Ver-

besserungen noch höher ausfallen.

Abbildung 4: Vergleich eines PV-Systems mit Wärmepumpe ohne SG Ready Regelung (links) und mit Regelung (rechts) aus der Polysun Co-Simulation. Oben: Leistungsflüsse an einem sonnigen Tag. Unten: Temperaturen in den Schichten des TWW-Speichers am selben Tag. PV-Nennleistung: 9,9 kWp; Wärmepumpen-Nennleistung: 3,3 kW (elektrisch), 10,1 kW (thermisch); Haushaltslastprofil: 5000 kWh/a; Verbrauch der Wärmepumpe: ca. 5400 kWh/a (je nach Betrieb ab-weichend).

5.2 PV-Abregelung

Die einfachste Möglichkeit, eine Begrenzung der PV-Netzeinspeisung auf einen vor-

gegebenen Wert zu gewährleisten, ist die Abregelung. Dies wird in der Regel von

PV-Systemen (z. B. SolarLog und SMA) implementiert. Allerdings verbessert sich der

Betrieb von Regelanwendungen, die als Eingangsargumente die theoretische

PV-Leistung vor der Abregelung benötigen, wenn sie mit der Abregelung kommuni-

zieren können, um diese abzuschätzen [14]. Aus diesem Grund wurde im Zuge die-

ser Untersuchung eine Subapplikation zur Abregelung entwickelt, welche einen

simplen PID- (engl. „proportional-integral-derivative“) Regler implementiert. Der

Stellwert ist dabei der gleitende 10-Minutenmittelwert der Netzeinspeisung (der Be-

zugszeitraum für das KfW-Förderprogramm „Erneuerbare Energien, Speicher“ [15]).

In einem realen System kann die Abregelung z. B. von Wechselrichtern, die das

„SunSpec open protocol for interoperability between devices in renewable energy

systems“ (deutsch: „SunSpec offenes Protokoll für Interoperabilität zwischen Gerä-

ten in regenerativen Energiesystemen“) implementieren, erfasst werden.

5.3 Prognosebasierter Betrieb von PV-Speichersystemen

Durch den intelligenten Betrieb von PV-Speichersystemen lassen sich Abregelungs-

verluste minimieren. Am einfachsten wird dies erzielt, indem die Batterie erst ab der

Einspeisegrenze beladen wird. Allerdings resultiert daraus gegenüber dem Stan-

dardbetrieb mit Einspeisebegrenzung ausschließlich durch Abregelung eine verrin-

gerte Ausnutzung der Batterie [16]. Durch die Einbindung von PV- und Lastprogno-

sen lässt sich eine dynamische Einspeisebegrenzung realisieren, welche diese Prob-

lematik behebt. Die Forschungsgruppe „Solarspeichersysteme“ entwickelte an der

HTW Berlin mit dem „PVprog“ Algorithmus eine modellbasierte Regelung in Matlab,

welche messwertbasierte PV- und Lastprognosen verwendet, um die Netzeinspei-

sung mit einer Batterie dynamisch zu begrenzen [1].

Dieser Algorithmus wurde im Zuge dieser Untersuchung auf eine IEC 61499 Sub-

applikation portiert (s. Abbildung 5) und anhand von Co-Simulationen mit dem von

der HTW zur Verfügung gestellten Matlab-Simulationsmodell validiert. Für eine er-

höhte Modularität entkoppelt die Subapplikation das Batteriemodell von der Optimie-

rung, wodurch eine geringe Änderung im Optimierungsalgorithmus vorgenommen

werden musste. Im ursprünglichen Matlab-Algorithmus wird in gleich großen Schrit-

ten durch Einspeisebegrenzungen zwischen 0 und 100 % iteriert und anhand der

Prognosen in jedem Schritt die Batterie 15 Stunden vorsimuliert. Das Optimum ist

Begrenzung, mit der die genutzte Batteriekapazität den prognostizierten

PV-Überschüssen am nächsten entspricht und gleichzeitig die maximal zulässige

Netzeinspeisung eingehalten werden kann.

PV-Prognosen

Lastprognosen

Optimierung

Batteriemodell

Regelung

Abbildung 5: Vereinfachte Darstellung der IEC 61499 Implementierung des PVprog Algorithmus.

Die IEC 61499 Implementierung erhöht die vorsimulierte Einspeisebegrenzung

schrittweise, bis das Batteriemodell bei einer weiteren Erhöhung nicht mehr voller

geladen werden kann oder bis die maximal zulässige Einspeisegrenze erreicht ist.

Aus der geänderten Herangehensweise resultiert eine leicht erhöhte Auflösung der

Iterationsschritte, was wiederum zu einer geringen Abweichung der Simulationser-

gebnisse führt. Der Autarkiegrad wird von 52,6 % auf 52,7 % erhöht und die Abrege-

lungsverluste von 0,9 % auf 1,4 %. Es handelt sich hierbei vermutlich um rein

stochastische Abweichungen. Nach der ersten Validierung wurde die Regelanwen-

dung des mit Polysun co-simulierten Systems von Abschnitt 5.1 um die

PVprog-Subapplikation und die Abregelung von Abschnitt 5.2 ergänzt und dem Sys-

tem eine nutzbare Batteriekapazität von 10 kWh hinzugefügt. Zusätzlich wird eine

Einspeisebegrenzung von 50 % vorgegeben.

Abbildung 6 vergleicht die Simulationsergebnisse mit (rechts) und ohne (links) Ein-

bindung der PVprog Subapplikation. Der Einsatz der Batterie stört die Regelung der

Wärmepumpe nicht, allerdings reicht er alleine nicht aus, um die Abregelung zur Mit-

tagszeit zu verhindern. Durch den prognosebasierten Betrieb kann die Batterie, so-

fern die SG Ready Subapplikation und die PVprog Subapplikation miteinander kom-

munizieren [14], fast alle Abregelungsverluste auffangen. Im co-simulierten System

erhöht sich der Autarkiegrad durch Hinzufügen der Batterie auf 39,5 % und durch

den prognosebasierten Betrieb auf 42 % (vgl. System in Abbildung 4, rechts). Der

Eigenverbrauchsanteil wird 44,7 % und dann auf 45,1 % erhöht. Es erfolgt eine Ver-

ringerung der Netzeinspeisung um weitere 2622 kWh. Durch den prognosebasierten

Betrieb erhöht sich diese wieder um 281 kWh. Der Netzbezug verringert sich durch

die Batterie um weitere 1606 kWh und durch den prognosebasierten Betrieb noch-

mals um 229 kWh.

Abbildung 6: Vergleich eines PV Systems mit SG Ready Wärmepumpe und Batterie (Leistungsflüsse an einem sonnigen Tag) mit sofortiger Batteriebeladung bei PV-Überschüssen (links) und mit progno-sebasierter Batteriebeladung. PV-Nennleistung: 9,9 kWp; Nutzbare Batteriekapazität: 10 kWh; Wärmepumpen-Nennleistung: 3,3 kW (elektrisch), 10,1 kW (thermisch); Haushaltslastprofil: 5000 kWh/a; Verbrauch der Wärmepumpe: ca. 5400 kWh/a (je nach Betrieb abweichend); Einspeisebegrenzung: 50 %.

6 Feldtest

Unter anderem beinhaltet die Zielsetzung dieses Projekts eine hohe Flexibilität und

die Minimierung der Prototypenphase dadurch, dass die entwickelten Regelanwen-

dungen mit möglichst geringen Änderungen an der Regellogik in realen Systemen

direkt einsetzbar sein sollen. Um dies zu erzielen, wurden die Schnittstellen zwi-

schen Simulationssoftware und Regellogik modular aufgebaut, sodass lediglich die

Kommunikationslogik der Regelanwendung angepasst werden muss (s. Abschnitt 4).

Mit kommerziellen IEC 61499 Entwicklungsumgebungen wie ISaGRAF und nxtSTU-

DIO ist bereits heute eine automatisierte Einstellung der Kommunikationslogik mög-

lich. Für 4diac ist dies ebenso geplant [5]. Zur Validierung, dass das Ziel erreicht ist,

wurde die PVprog-Subapplikation aus Abschnitt 5.3 auf einer Raspberry Pi 2 instal-

liert und in einem echten PV-Speichersystem getestet.

6.1 Aufbau

Die Regelanwendung wurde im „Living Equia” Haus der HTW Berlin [17] aufgebaut.

Das Gebäude hat eine PV-Anlage mit einer Nennleistung von 4,6 kWp und einer

Sonnenbatterie mit einer vom Hersteller angegebenen nutzbaren Kapazität von

5,3 kWh. Um diese ansteuern zu können, wurde zunächst ein Modul für die 4diac

Laufzeitumgebung entwickelt, die das HTTP Kommunikationsprotokoll implementiert.

Damit war es möglich, eine IEC 61499 Funktionsblock-Bibliothek für die Sonnenbat-

terie API (engl. „Application Programming Interface”) [18] zu programmieren. Der

Aufbau des Feldtests wird in

Abbildung 7 visualisiert. Die Regelanwendung auf dem Raspberry Pi bezieht Sys-

temmesswerte von einem RESTful Server, welcher auf der Sonnenbatterie gehostet

wird.

TCP/IP

SSH

Abbildung 7: Visualisierung des Feldtestaufbaus und der Kommunikationspfade.

Status und Messwertverlauf des PV Speichersystems können einerseits über ein

Web Interface der Batterie, andererseits zusammen mit Informationen über den ak-

tuellen Status der Regelung per TCP/IP direkt von der Regelanwendung abgerufen

werden. Der Zugriff auf das Betriebssystem des Raspberry Pi (Raspbian), auf dem

die 4diac Laufzeitumgebung ausgeführt wird, erfolgt über SSH.

6.2 Ergebnisse

Die Leistungsflüsse im Feldtest sind in Abbildung 8 für einen ausgewählten sonnigen

Tag dargestellt. Sie beweisen, dass die IEC 61499 PVprog-Regelanwendung in ei-

nem realen System wie vorgesehen agiert. Am frühen Morgen wird die dynamische

Einspeisegrenze niedrig angesetzt und im Laufe des Tages an die hohe PV-Leistung

angepasst. Die Wolken am späten Nachmittag führen dazu, dass die Grenze wieder

herabgesetzt wird. Gründe für die zunächst niedrige Einspeisegrenze am Morgen

können umfassen:

i) Starke Verschattungen am Morgen oder am Abend des Vortages.

ii) Die Regelanwendung befindet sich noch in der Initialisierungsphase, die bis

zu 10 Tage andauern kann, wenn vorher kein komplett sonniger Tag auftritt.

iii) Die letzten 10 Tage waren stark bewölkt, was zu einer unvollständigen Initiali-

sierung der PV-Prognosen führen kann.

iv) Die nutzbare Batteriekapazität ist (z. B. durch Degradation) niedriger als vom

Hersteller angegeben.

In diesem Fall war der Vortag komplett unbewölkt, was (ii) und (iii) als möglichen

Grund ausschließt. Neben (iv) könnte (i) ein Grund sein, da die Messwerte im Sep-

tember aufgenommen wurden – einer Zeit, in der die PV-Leistung aufgrund der fal-

lenden Sonnendeklination täglich etwas reduziert wird, vor allem zu den Morgen- und

Abendstunden, in denen die Horizontverschattung am prominentesten ist. Die Hori-

zontverschattung sollte für die Systemeffizienz kein Problem darstellen. Der verrin-

gerten nutzbaren Batteriekapazität kann entgegengewirkt werden, indem die Regel-

anwendung um eine Subapplikation ergänzt wird, die während der nächtlichen Batte-

rieentladung die nutzbare Kapazität neu abschätzt. Deren Auslösung könnte durch

einen Ladezustand von 100 % erfolgen. Die abgeschätzte Kapazität in kWh ent-

spricht einer Integration über den Batterietransfer bis zur leeren Batterie.

Abbildung 8: Gemessene Leistungsflüsse (unten) und Batterieladezustand (oben) an einem ausge-wählten Tag während des Feldtests der IEC 61499 PVprog-Subapplikation auf einer Raspberry Pi 2. Auflösung: 1 min. PV-Nennleistung: 4,6 kWp; nutzbare Batteriekapazität: 5,3 kWh.

7 Fazit

Die Energieflüsse des Feldtestaufbaus in Abbildung 8 zeigen eine klare zeitliche

Verschiebung der Batteriebeladung in die Mittagszeit, wodurch die PV-Abregelung

verhindert wird. Folglich erweisen sich die verwendeten Simulationsprogramme Po-

lysun und Matlab als zuverlässige Entwicklungshilfen für IEC 61499 Regelanwen-

dungen, die direkt auf eine Vielzahl von Hardware implementiert werden können.

Dem Bedarf an generischer standardbasierter Software wurde mit einer kompletten

open source Lösung entgegengekommen.

Zukünftig geht es darum weitere Kommunikationsprotokolle sowie robuste Stan-

dard-Regelalgorithmen für Multi-Erzeuger- und Multi-Speicheranwendungen zu ent-

wickeln und zu implementieren.

Quellcode

• PVprog Algorithmus in Matlab: pvspei-

cher.htw-berlin.de/veroeffentlichungen/daten/ pvprog

• tcpip4diac: Matlab-Bibliothek zur Kommunikation mit IEC 61499

SPS-Anwendungen: github.com/MrcJkb/tcpip4diac

• Polysun4diac: Polysun-Plugin und JAVA Bibliothek zur Kommunikation mit

IEC 61499 SPS-Anwendungen:

github.com/MrcJkb/Polysun-4diac-ControllerPlugin

• IEC 61499 Funktionsblock-Bibliothek und SPS-Anwendungen:

github.com/MrcJkb/PVTControllerLib

• HTTP-Kommunikationsmodul für 4diac-RTE:

github.com/MrcJkb/forte_http_comm

Literaturverzeichnis

[1] J. Bergner, J. Weniger, und T. Tjaden, PVprog-Algorithmus - Algorithmus zur Umsetzung der prognosebasierten Batterieladung für PV-Speichersysteme mit messwertbasierten PV- und Lastprognosen. Berlin: Hochschule für Technik und Wirtschaft HTW Berlin, 2016.

[2] International Electrotechnical Commission (IEC), Hrsg., IEC 61131 Pro-grammable controllers. Geneva: International Electrotechnical Commission (IEC), 1993.

[3] International Electrotechnical Commission (IEC), Hrsg., IEC 61499 Function blocks, 2. Aufl. Geneva: International Electrotechnical Commission (IEC), 2012.

[4] W. Bolton, Programmable logic controllers. Kidlington, Oxford, UK; Waltham, MA: Newnes, 2015.

[5] A. Zoitl und T. Strasser, Distributed control applications: guidelines, design pat-terns, and application examples with the IEC 61499. 2016.

[6] „IEC 61499 Compliance Profile for Feasibility Demonstrations“, 29-Mai-2017. [Online]. Verfügbar unter: http://holobloc.com/doc/ita/index.htm. [Zugegriffen: 29-Mai-2017].

[7] A. Zoitl, Modelling control systems using iec 61499, 2nd edition. Stevenage, Herts, United Kingdom: The Institution of Engineering and Technology, 2014.

[8] 4diac. Munich: Fortiss GmbH. [9] Polysun. Winterthur: Vela Solaris AG. [10] „SG Ready-Datenbank | Bundesverband Wärmepumpe (BWP) e.V.“, 02-Aug-

2017. [Online]. Verfügbar unter: https://www.waermepumpe.de/normen-technik/sg-ready/sg-ready-datenbank/. [Zugegriffen: 02-Aug-2017].

[11] T. Tjaden, J. Weniger, und V. Quaschning, „Richtige Dimensionierung von Pho-tovoltaik, Wärmepumpen und Pufferspeichern“, gehalten auf der C.A.R.M.E.N.-Symposium 2017, Straubing, 11-Juli-2017.

[12] Bundesverband Wärmepumpe e. V., „Regularien des SG Ready-Labels“, SG Reagy-Label - für das Smartgrid geeignete Wärmepumpen, 16-Dez-2014. [Onli-

ne]. Verfügbar unter: http://www.waermepumpe.de/fileadmin/redakteurdaten/Waermepumpe/Qualitaet/SG_READY/2012-11-01_SG_Ready_Regularien_Version1.1.pdf. [Zugegriffen: 16-Dez-2014].

[13] T. Tjaden, „PV-Systeme mit Wärmepumpe ideal betreiben“, pv magazine, S. 106–108, Feb-2015.

[14] M. Jakobi, „Development of model-based control applications compliant with IEC 61499 with a focus on PV“, Master’s thesis, HTW Berlin, Berlin, 2017.

[15] Forum Netztechnik/Netzbetrieb im VDE (FNN), „Anschluss und Betrieb von Speichern am Niederspannungsnetz“, Forum Netztechnik/Netzbetrieb im VDE (FNN), Berlin, Juni 2014.

[16] J. Weniger, „Dimensionierung und Netzintegration von PV-Speichersystemen“, Masterthesis, Hochschule für Technik und Wirtschaft Berlin, Berlin, 2013.

[17] „Solar Decathlon Europe 2010 - Living Equia - Teilprojekt HTW Berlin (ENOB) (SD Europe (BMWi-Energieoptimiertes Bauen Bundesförderung)) - Hochschule für Technik und Wirtschaft Berlin University of Applied Sciences - HTW Berlin“, 21-Sep-2017. [Online]. Verfügbar unter: http://www.htw-berlin.de/forschung/online-forschungskatalog/projekte/projekt/?eid=1161. [Zugegriffen: 21-Sep-2017].

[18] „Sonnenbatterie API for battery systems operated in slave mode“. Sonnenbatte-rie GmbH, 2013.