Betriebliche Praxis ist, dass Maschinen in Pausen, über Nacht oder an Wochenenden nicht abgeschaltet werden. Vor allem haben die Betreiber Bedenken, dass die Maschinen nicht rechtzeitig wieder produktionsbereit sind oder beim Hochlauf Fehler auftreten, wodurch erhöhte Stillstandzeiten und damit Kosten entstehen. Folge ist, dass diese Maschinen auch in nicht produktiven Zeiten sehr viel Energie verbrauchen. Um dieses Problem zu lösen, wurde mit Feldbusprofilen wie Sercos Energy oder ProfiEnergy die Grundlage geschaffen, einzelne Verbraucher, – zum Beispiel durch Vorgabe von Pausenzeiten – in energiesparende Zustände zu schalten.

Neben dem normalen Betriebszustand (Betriebs-Energiemodus) werden hierbei mehrere Zustände des Verbrauchers unterschieden, die sich durch den Energieverbrauch, die Übergangszeiten vom und zum Betriebs-Energiemodus und den Energieverbrauch während der Übergänge unterscheiden. Zusätzlich können minimale und maximale Verweildauern im Energiemodus vorhanden sein. Diese Daten sind üblicherweise als geräteabhängige, fest hinterlegte Parameter im Verbraucher abgelegt.

Für die Unterstützung bei der Nutzung der genannten Feldbusprofile sind verschiedene Lösungen bekannt. Zum einen sind von einigen Steuerungsherstellern Funktionsbausteine verfügbar, die die Kommunikation mit dem Verbraucher – zum Beispiel das Auslesen der Konfiguration und das Schalten der Verbraucher über die Feldbusprofile – unterstützen. Zum anderen existieren vollständige monolithische Energiemanagement-Lösungen, die auch eine Aggregation der Daten auf Maschinenebene und Vorgabe-Schnittstellen zum HMI oder einem Leitsystem bieten.

Ein Manko bei reinen Kommunikationsbausteinen ist, dass bei diesen üblicherweise keine Abbildung der Verbraucher auf Maschinenebene stattfindet. Dies ist insofern problematisch, da üblicherweise die Maschine über das HMI oder ein Leitsystem beziehungsweise ein Manufacturing Execution System (MES) durch eine Vorgabe komplett geschaltet werden soll. Die Programmierung von zentralen Befehlsquellen, deren Priorisierung sowie die Anbindung der Kommunikationsbausteine an diese Befehlsquellen obliegt hierbei dem Anwender. Dies bedeutet einen hohen Aufwand bei der Realisierung des Energiemanagements.

Alternativ hierzu besteht die Möglichkeit, einen zentralen Energiemanagement-Funktionsbaustein (EM FB) als Teil einer übergreifenden Energiemanagement-Lösung zu programmieren. Dieser verfügt über definierte Schnittstellen für die Anbindung von HMI und MES/Leitsystemen oder Vorgaben aus der Applikation und priorisiert diese. Die Anbindung der Verbraucher über die in den Feldbusprofilen definierten Mechanismen erfolgt dabei ebenfalls im zentralen Funktionsbaustein. Schwierigkeiten bereitet diese monolithische Lösung bei modularen Applikationsarchitekturen. Hier erfolgt die Kommandierung der Verbraucher üblicherweise in den Modulen, die den – oft auch mechanisch getrennten – Maschinenmodulen zugeordnet sind. Jedoch wird diese Aufgabe auch von einem zentralen Energiemanagement übernommen, welches die Verbraucher über die Feldbusprofile schaltet, was wiederum dem Prinzip der modularen Programmierung widerspricht und den Aufwand bei einem Austausch, Entfernen oder Instanziieren von Modulen deutlich erhöht.

Die Architektur der Lösung

Als Ansatz für das Energiemanagement wurde eine objektorientierte Lösung gewählt. Für die Architektur wurden verschiedene Klassen von Funktionsbausteinen (FB) definiert:

■ FB zur Kommandierung (Command-Bausteine),
■ FB zur Energieverwaltung (EnergyControl-Bausteine),
■ FB zur Energiemodusvorgabe (Device-Bausteine).

Bei der klassischen Lösung müssen Strukturen instanziiert werden, welche über Pointer (zum Beispiel VAR_IN_OUT) an die Bausteine angelegt werden. Hierbei ist ein Nachteil, dass zyklisch geprüft werden muss, ob ein anderer Baustein aktuell eine der möglichen Vorgaben oder Anfragen hat. Dies kann in einer objekt­orientierten Lösung, bei der die Bausteine über definierte Interfaces kommunizieren, durch Methoden oder Eigenschaften ereignisgesteuert erfolgen.

© Bosch Rexroth

Die einzelnen Funktionsbaustein-In­stanzen machen sich über die Deklaration bei der Initialisierung des Programms nach dem Projekt-Download untereinander bekannt. Durch die Verwendung von Interfaces ist der Anmelde-Mechanismus nicht von konkreten Funktionsbaustein-Typen abhängig.

Die Command-Bausteine (Cmd-FB) dienen dazu, Vorgaben an das Energiemanagement in Form von Pausenzeiten oder bestimmten Energiemodi zu übergeben. Command-Bausteine werden zum Beispiel für folgende Vorgabequellen instanziiert:

■ MES oder Leitsysteme, zur Vorgabe geplanter produktionsfreier Zeiten;
■ HMIs, zum Abschalten durch den Maschinenbediener;
■ Applikation, wenn beispielsweise automatisch Teilemangel erkannt wird.

Die Command-Bausteine können auch an einem EnergyControl-Baustein angemeldet werden, welcher stellvertretend für die Hierarchie der Maschine steht. Bei diesem wird wiederum für jeden Verbraucher ein Device-Baustein angemeldet. Die Device-Bausteine stehen stellvertretend für die Hierarchie der Verbraucher. Sie erhalten die Vorgaben vom EnergyControl-Baustein und übernehmen die Kommunikation mit dem Verbraucher. Dies kann sowohl über die spezifizierten Energie-Feldbusprofile als auch – bei Ver­wendung von generischen Device-Bausteinen für Verbraucher ohne Energie-Feldbusprofil – durch die Applikation erfolgen.

Um etwa dem HMI eine höhere Priorität zuordnen zu können als einem Leitsystem/MES, sind die Command-Bausteine gegenseitig priorisierbar. Die Priorität wird über die Konfiguration der Command-Bausteine vorgegeben und vom EnergyControl-Baustein ausgewertet. Für die direkte Vorgabe von Energiemodi werden für den EnergyControl-Baustein ähnlich zu den Energiemodi in den Feldbusprofilen Energiemodi der Maschine definiert. Die Energiemodi der einzelnen Verbraucher sind dann den Energiemodi der Maschine tabellarisch zuzuordnen. Hierbei werden typischerweise nicht alle Kombinationen der Energiemodi der Verbraucher abgebildet, sondern nur die sinnvollen Maschinenzustände berücksichtigt.

Wie im Bild (oben) dargestellt, können zum Abschalten von einzelnen Verbrauchern die Command-Bausteine direkt an den Device-Bausteinen angemeldet werden. Dies ist zum Beispiel dann sinnvoll, wenn während des Betriebs, in Abhängigkeit vom Maschinenzustand, zeitweise einzelne Verbraucher abgeschaltet werden sollen. Wäre dies nicht möglich, müsste für jede dadurch auftretende Kombination ein Energiemodus für die Maschine definiert werden, was wiede­rum einen hohen Konfigurationsaufwand zur Folge hätte.

Applikationen mit modularer Architektur

Die objektorientierte Architektur verbindet die Vorteile eines zentralen Energiemanagements beziehungsweise einer zentralen Vorgabe-Schnittstelle für die ganze Maschine mit denen der dezentralen Verwendung von Kommunikationsbausteinen für die Feldbusprofile. Die Device-Bausteine lassen sich in den Software-Modulen der Applikation instanziieren und bei der zentralen Instanz des EnergyControl-Bausteins anmelden. Dadurch wird das Energiemanagement bei der Initialisierung des Programms auf der Steuerung „verknüpft“.

Durch Verwendung der Funktionsbausteine in den Applikations-Modulen unterstützt das objektorientierte Energiemanagement die Freiheitsgrade der modularen Programmierung.

© Bosch Rexroth

Die Kommunikation zwischen den Bausteinen erfolgt über Methoden und Properties „unter dem Blech“, das heißt ohne weiteres Verschalten des Anwenders. Dadurch sind keine Erweiterungen der Schnittstellen zwischen dem zentralen Applikationsteil und den Modulen notwendig. Alternativ zum objektorientierten Ansatz wären beispielsweise große, unübersichtliche Strukturen notwendig, die an alle beteiligten FB angeschlossen werden müssten. Aber auch diese Verbindungen müssten vom Anwender bei einer Änderung der Module am zentralen Baustein nachgepflegt werden. Das objekt­orientierte Energiemanagement hingegen ist auch mit minimalen Änderungen an bestehenden Applikationen nachrüstbar, da die vorhandenen Schnittstellen zwischen zentraler Organisation der Appli­kation und den Modulen nicht erweitert werden müssen.

Mehrere Verbraucher gleichzeitig abschalten

Gilt es, einzelne Module oder Gruppen von Verbrauchern gleichzeitig abzuschalten, so lassen sich durch Kaskadierung von EnergyControl-Bausteinen Gruppen bilden. Die untergeordneten Bausteine werden hierzu beim übergeordneten Baustein als Device angemeldet. Der hierarchisch höchste EnergyControl-Baustein übernimmt dabei die Verwaltung der Maschinen-Energiemodi. Der Vorteil bei der Kaskadierung der Bausteine liegt darin, dass Gruppen von Verbrauchern über einzelne Command-Bausteine geschaltet werden können. Ohne Kaskadierung müsste für jeden Verbraucher der zu schaltenden Gruppe ein Command-Baustein instanziiert und angesteuert werden.