Applikationen (Anwendungen) zur Automatisierung eines verteilten Systems
IEC61499-Applications sind Netzwerke aus Function-Block-Instanzen. Ähnlich der Instanziierung der Funktionsbausteine in der SPS-Norm 61131 werden auch hier Exemplare der Function-Block-Typen mit jeweils eigenem Speicherraum und eigenem Namen erzeugt und miteinander vernetzt. Die Gesamtheit der vernetzten FB-Instanzen definiert die Funktionalität der Automatisierungslösung. Eine Applikation hat kein Interface, sie bildet keinen eigenen Typ und kann daher auch nicht erneut instanziiert werden. Typische Applikationen sind eine komplette Heizungs- oder Lüftungsanlage, eine Fertigungsmaschine, eine Verpackungsanlage. Der Konstrukteur kann eine Applikation entwickeln, ohne zuvor festzulegen, auf welchen und auf wie vielen Devices die Anwendung ablaufen soll. Er kann sich zunächst auf die Logik und den Zusammenhang der Prozessautomatisierung konzentrieren, erst im Nachhinein die Device-Anzahl festlegen und dann die entwickelten Function Blocks auf die beteiligten Steuerungen verteilen. Motive zur Verteilung könnten z.B. sein, spezielle Devices für Eingänge oder Ausgänge zur Prozessanbindung zu verwenden, die Devices prozessnah in einem weitläufigen Prozess zu verteilen oder spezielle Devices für schnelle Berechnungen oder zur Speicherung von Daten einzusetzen. Bild 4 zeigt im unteren Teil ein automatisiertes System aus vier Devices, auf denen die Applications A, B und C angesiedelt sind. Die Anwendung A umfasst beispielhaft drei Function Blocks, die verteilt auf den Devices 1 bis 3 angesiedelt sind. Um ihre gemeinsame Aufgabe zu erfüllen, müssen sie über das Kommunikationsnetz Daten und Events austauschen, anstatt Device-intern zu kommunizieren. Diese erst durch die Verteilung notwendige Kommunikation wird durch die oben genannten Service Function Blocks verwirklicht.
Verteilung einer Anwendung auf mehrere Devices
Die Zuordnung von Teilen einer Applikation auf die beteiligten Devices wird Mapping genannt. In der Entwicklungsoberfläche nxtStudio (Fa. nxtControl GmbH, www.nxtControl.com) kann der Anwender ausgewählte Teile seines Applikationsnetzwerks besonders einfach markieren und einem der im System verfügbaren Devices zuordnen. Bild 1 zeigt im oberen Fenster die gesamte Applikation. Im unteren Fenster erkennt man die auf das ausgewählte Device DEV0 gemappten Bausteine inputXY, ctlX und compcyl1, die im oberen Fenster weiß (das heißt, bereits gemappt) dargestellt sind. Der unten gezeigte Start-Block befindet sich per Default auf der Device-Ressource RES0 (als CPU des Devices zu verstehen), stellt die Verbindung zum Laufzeitsystem der Ressource her und generiert das INIT-Signal beim Kaltstart des Devices. Beim Mappen werden auf diese Weise alle Teile der Applikation einem der Devices zugeordnet. nxtStudio nimmt dem Programmierer die manuelle Erstellung der Kommunikationsverbindungen zwischen den verteilten Bestandteilen ab und erzeugt sie selbsttätig. Dies erspart erhebliche Projektierungsarbeit und unterstützt damit die Verteilung. Auch die nachträgliche Änderung der Verteilung wird dadurch sehr einfach. Beim Download der Applikation auf die beteiligten Steuerungen – dem sogenannten Deployment – erhält jedes Device automatisch diejenigen Teile der Applikation, die ihm beim Mappen zugeordnet wurden.
CAT: Objektorientierte Automatisierung mit dem nxtStudio
Die Entwicklungsoberfläche nxtStudio bietet als Erweiterung zu den Function-Block-Möglichkeiten der 61499-Norm einen weiteren Block-Typ, den sogenannten Composite Automation Type, abgekürzt CAT. Der CAT stellt ein Software-Objekt dar, mit dem man im Sinne der objektorientierten Programmierung Objekte einer automatisierten Anlage abbilden kann.
