Kapitel 6: Fragen und Antworten

Objekte der realen Welt sind in der Automatisierungstechnik die Feldgeräte, also die Sensoren und Aktoren, die als Objekte zu programmieren sind. Diese zahlreichen Feldgeräte einer Anlage basieren meist auf einer überschaubaren Menge unterschiedlicher Feldgerätetypen, die als Klassen in Funktionsbausteinen programmiert werden. Objekte sind Instanzen der Klassen, meist werden globale die Instanzvariablen als Datenbausteine deklariert.

Methoden dienen zur Ansteuerung von Feldgeräten, z.B. zum Ein- und AUsschalten eines Motors, zur Anwahl der Betriebsart oder Aktivierung eines Reglers.

Die Eigenschaften (Properties) von Funktionsbausteinen geben ihren Status an, z.B. ob ein Motor
läuft oder nicht, welchen Messwert ein Sensor einliest, in welcher Betriebsart eine
Einzelsteuerfunktion ist.

Einer Schrittkette oder anderen Programmen werden Sensordaten als Eigenschaften zur Verfügung gestellt. Die Ansteuerung der Feldgeräte aus der Schrittkette heraus erfolgt durch Methoden.

Ein Funktionsbaustein kann seine Methoden und Eigenschaften an einen anderen Funktionsbaustein
vererben. Dies ist vor allem sinnvoll, wenn beide Funktionsbausteine große
Teile der Software gemeinsam nutzen, wie im Fall der Funktionsbausteine TYP_IDF1
und TYP_IDF2 für Motoren mit ein bzw. zwei Drehrichtungen.

Durch das Schlüsselwort EXTENDS in der Deklaration

FUNCTION_BLOCK TYP_IDF2 EXTENDS TYP_IDF1

werden die Methodenund Eigenschaften vom Funktionsbaustein TYP_IDF1 an den Funktionsbaustein
TYP_IDF2 vererbt. Somit müssen sie nicht noch einmal im Funktionsbaustein TYP_IDF2 programmiert
werden.

Geerbte Methoden können überschrieben werden, indem die Eltern-Methode mit

SUPER^.Methode();

in der neuen Methode aufgerufen und dann verändert wird.

Eine Schnittstelle (Interface) listet alle Methoden und Eigenschaften einer Klasse auf. Schnittstellen
enthalten jedoch nur die Deklaration, keine Implementation der Methoden und Eigenschaften.
Der Code wird immer innerhalb des Funktionsbausteins implementiert.

Bei der Deklaration des Funktionsbausteins wird durch den Befehl IMPLEMENTS der Bezug zur Schnittstelle
angegeben, wie z.B. durch:

FUNCTION_BLOCK TYP_IDF1 IMPLEMENTS Drive1

Das Interface selbst stellt sozusagen nur die leere Hülle eines Funktionsbausteins dar.
Schnittstellen können wie Funktionsbausteine auch vererbt werden, z.B. durch die Definition

INTERFACE Drive2 EXTENDS Drive1

Ploymorph heißt vielschichtig. Funktionsbausteine sind polymorph, wenn sie auf unterschiedliche Arten genutzt werden können.  Dies ist der Fall, wenn sie gleichnamige Methoden einer Schnittstelle nutzen, die unterschiedlich implementiert sind.

Beispielsweise können Grundfunktionen unterschiedliche Motortypen über die Methode ON1 ansteuern. Ist der Grundfunktion ein Ein/Aus-Motor mit der Schnittstelle Drive zugeordnet, wird in der Methode ON1 des Bausteins TYP_IDF1 ein Relais angesteuert, das den Motor aktiviert.

Ist der Grundfunktion dagegen ein Schrittmotor mit der gleichen Schnittstelle Drive zugeordnet, startet die Methode ON1 im Funktionsbaustein TYP_SMOT ein Taktsignal, das den Schrittmotor aktiviert. Die gleiche Methode ON1 ist also in den Funktionsbausteinen TYP_IDF1 und TYP_SMOT unterschiedlich implementiert. Die Grundfunktion, die die Methode ON1 startet, weiß nicht welchen Motortyp sie aktiviert. Sie kann also unterschiedliche Motortypen ansteuern.

Auf die gleiche Art können auch unterschiedliche Regler (z.B. PID-Regler oder Dreipunktregler) angesteuert werden.

Ein Rezept besteht aus einer Aneinanderreihung mehrerer Grundoperationen als Schrittkette. Eine Grundoperation ist eine Schrittkette, die mehrerer Grundfunktionen ananeinanderreiht. Eine Grundfunktion ist der kleinste Verfahrensschritt, in den man den Herstellungsprozess zerlegen kann. Sie wir auch als Schrittkette programmiert und steuert die Feldgeräte an.

Schritt 1: Zerlegung des Prozesses in verschiedene Tätigkeiten, die zur Herstellung des Produktes automatisiert oder manuell durchgeführt werden müssen.

Schritt 2: Entwurf von Grundfunktionen, die die ermittelten Tätigkeiten in Form von Ablaufketten unabhängig von bestimmten Geräten in der Anlage modellieren.

Schritt 3: Komposition des Rezepts durch Zusammensetzung der Grundfunktionen zu Grundoperationen und der Grundoperationen zum Grundrezept.

Schritt 4: Zuordnung der Feldgeräte in der Anlage zu den Grundfunktionen.

Das Rezept setzt sich aus den entwickelten Grundfunktionen so zusammen, wie der zu steuernde Prozess in Schritt 1 des Rezeptentwurfs zerlegt wurde. Das Rezeptprogramm ist eine Schrittkette, die nacheinander die Grundoperationen des Prozesses ansteuert. Jede Grundoperation wird als ACTION in der Ablaufsprache auch als Schrittkette programmiert und ruft in ihren Schritten die Grundfunktionen der einzelnen Prozessphasen wiederum als ACTION auf. Diese ACTIONs sind nun in der Funktionsbausteinsprache erstellt und instanziieren die Funktionsbausteine der Grundfunktionen aus Schritt 2.

Die Zuordnung der Feldgeräte zu den Grundfunktionen erfolgt in den ACTIONs der Prozessphasen, wo die Instanzvariablen der Feldgeräte 
mit den Prototypen der Grundfunktionen verknüpft werden. Die Instanzvariablen der Feldgeräte müssen hierfür das gleiche Interface haben
wie die Prototypen.

Für die Anlagenteile werden Funktionsbausteine entwickelt, die in verschiedenen Anlagen einsetzbar sind (s. Bilder 6.18-6.21). Diese Bausteine werden nun in Ansteuerprogrammen für die Teilanlagen, wie z. B. im Programm Boiler in Bild 6.24, instanziiert. Dazu sind die Datenbausteine der Feldgeräte den Ein-/ Ausgangsvariablen der Anlagenteile zuzuordnen.

Anstatt also jedes Feldgerät einzeln zu instanziieren, muss dies nur für jeden Anlagenteil erfolgen. In Bild 6.24 wird auch die globale Deklaration der Feldgeräte und die Zuweisung der Kanaladressen der SPS-Ein- und -ausgänge vorgenommen, ohne die die Ansteuerung der Feldgeräte nicht funktionieren würde.

Der entworfene Rezeptablauf wird nach IEC 61512 auch als Grundrezept bezeichnet, das wie ein Kochrezept auf verschiedenen Anlagen gleichen Typs eingesetzt werden kann. Durch die Zuordnung der Feldgeräte wird das Rezept anlagenspezifisch. Es kann
damit aber immer noch für die Herstellung mehrerer Chargen verwendet werden.

Ein Steuerrezept dient zur Herstellung einer Charge. Eine Charge ist das Produkt, das bei einem Durchlauf des Rezepts hergestellt wird. Zu ihrer Herstellung werden verschiedene Rezeptparameter, wie z. B. die Produktmenge, als Sollwerte für das Rezept vorgegeben.

• Nachteil:
• Ansteuerlogik wird verteilt auf zahlreiche Methoden und Eigenschaften und ist nicht mehr auf einem Blick im Funktionsplan überschaubar.
• Vorteile:
• Weniger Programmieraufwand insbesondere bei Erweiterungen, weil durch Vererbung
• viel Code nicht noch einmal programmiert werden muss.
• Übersichtliche Strukturen durch Methoden und Eigenschaften, mit denen der Datenverkehr
• zwischen Ansteuerprogrammen (und Schrittketten) statt mit globalen Variablen organisiert wird.
• Anlagenneutrale Planung des Prozessablaufs durch polymorphe Grundfunktionen
• mit abstrakten Schnittstellen, für die im Rahmen des Rezepts nachträglich unterschiedliche
• Feldgeräte zugeordnet werden können.