Komponentenemu­lation

Die Trennung von Applikation und Kommunikation ist seit jeher ein konzeptionelles Entwurfsmittel in der Automation. Dies erfolgt jedoch fast ausschließlich zur Designzeit. Die Strukturen der Feldgeräte sind damit zwar modular, diese Modularität von Applikation und Kommunikation wird jedoch weitestgehend nur beim Feldgerätehersteller für die Weiterentwicklung genutzt. Die Flexibilität und auch die Dauer der Entwicklung der Geräte ändern sich somit kaum. In diesem Zusammenhang ist es wünschenswert, eine leistungsfähige und flexible Plattform für die Implementierung von Applikationsfunktionen zu haben. Diese Plattform soll es ermöglichen, die Designzeit der Applikationen und damit auch die des gesamten Feldgerätes deutlich zu verkürzen, um bereits zu einem frühen Zeitpunkt der Entwicklung die Funktionalität eines komplexen Gesamtsystems nachbilden und testen zu können. Vor diesen Hintergründen wurde das Generic Device entwickelt, welches es ermöglicht beliebige Applikationssoftware in Modulen von virtuellen Feldgeräten verteilt umzusetzen.

Aufbau des Generic Devices

Das Generic Device ist ein modulares, frei konfigurierbares Software-Feldgerät. Der Aufbau des Gerätes ist in Bild 1 zu sehen. Es besteht aus drei funktionalen Teilen und einem, hier nicht dargestellten, Teil, welcher für die interne Verwaltung und Konfiguration zuständig ist. Die Konfiguration erfolgt mittels einer XML-Datei, welche dem Generic Device als Startparameter übergeben werden muss. In ihr sind alle wesentlichen Konfigurationsdaten für den Hochlauf des Feldgeräts festgehalten.

Der Feldbus-Geräte-Stack ist unabhängig von den verwendeten Applikationen und wird durch den generischen Data Container gekapselt. Er ist zuständig für die Kommunikation entsprechend der Konfiguration durch die XML-Datei. Über eine generische Schnittstelle kann vom Stack aus auf die Application Process Objects (APOs) im Data Container zugegriffen werden.

Der Data Container ist ein generischer Container für die APOs. Er verfügt über eine generische Schnittstelle für den Zugriff auf die APOs. Die Zugriffe erfolgen je nach gewünschtem Zeitfenster und gewünschter Datenkonsistenz entweder ausschließend oder konkurrierend. Für die zyklische Kommunikation werden ausschließende Zugriffe verwendet, um sicherzustellen, dass eine vollständige Momentaufnahme an die Steuerung übermittelt wird. Für die azyklische Kommunikation hingegen können dennoch zeitgleich andere Daten im Data Container verändert und gelesen werden, ohne dass eine Verfälschung der Prozessdaten erfolgt. Weiterhin können auch Berechtigungen für die einzelnen Daten im Data Container gesetzt werden, so dass bestimmte Zugriffe und damit ungewollte Veränderungen der Daten von vornherein ausgeschlossen werden können.

Ein weiterer Bestandteil des Generic Devices sind die Feldgeräteapplikationen. Diese sind als Softwarekomponenten (dynamisch gelinkte Bibliotheken) realisiert, welche die Kernfunktionalität des Software-Feldgerätes implementieren und bei Bedarf geladen werden. Sie sind feldbusunabhängig und können prinzipiell durch den generischen Data Container an jedem in das Generic Device integrierten Feldbusstack betrieben werden. Das Instanziieren von Feldgeräteapplikationen erfolgt ähnlich einem modularen Gerät durch das dynamische Stecken und Ziehen von Modulen. Die Konfiguration der einzelnen gesteckten Applikationen erfolgt zum einen durch je einen XML-Knoten, welcher beim Erstellen der Applikation übergeben wird, und zum anderen durch die übliche, azyklische Parametrierung des Geräts zum Verbindungsaufbau. Das Augenmerk bei der Umsetzung des Konzepts der busunabhängigen Applikationen lag auf der leichten Implementierbarkeit und der zukünftigen Erweiterbarkeit des Gerätes um weitere Applikationen.

Einige Beispiele für Feldgeräteapplikationen auf dem Generic Device werden im Folgenden aufgeführt. Eine Möglichkeit ist die Anbindung an einen realen Prozess mittels PC-IO-Hardware (z.B. Digital-IO). Hierbei werden bevorzugt Geräte mit USB-Anschluss verwendet, da diese ohne erheblichen Aufwand in handelsüblichen IT-Virtualisierungslösungen integrierbar sind. Weiterhin ist eine Logging-Applikation für Prozesswerte und Ereignisse vorgesehen. Ebenso ist eine generische Geräteapplikation umsetzbar, welche die Auslagerung von Teilen der Leitsystemapplikation und deren Verteilung mittels IEC 61499 Function Blocks ermöglicht. Eine Anbindung an externe Datenquellen durch die Message Oriented Middleware Active MQ ermöglicht die Einspeisung von Simulationsdaten in eine reale Feldbusumgebung, so dass auch Teilanlagen in einer realen Anlage simuliert werden können.

Feldgerätevirtualisierung

Durch die steigende Leistungsfähigkeit von PC-Komponenten ist eine Nutzung von Hardware-Virtualisierungslösung möglich. Dabei handelt es sich um eine Abstraktionsschicht, welche die Ressourcen eines Host-Systems mehreren speziellen und angepassten Gast-Systemen zur Verfügung stellt. Hierbei ist die verwendete Hardware von untergeordneter Rolle, da sie lediglich die Plattform für eine Virtualisierung darstellt.

Ein wesentlicher Aspekt bei der Virtualisierung der Geräte ist die Reduzierung des Aufwandes für eine Simulation von (Teil-)Anlagen, wobei reale und virtuelle Geräte beliebig mischbar sind. Hierfür ist eine Applikation für das Generic Device vorhanden, welche eine Simulationssoftware anbindet. Ebenso ist auch eine Applikation verfügbar, welche über die Peripherie des PCs einen realen Prozessanschluss ermöglicht

Durch eine leistungsstarke Virtualisierungsumgebung aus dem IT-Umfeld kann eine sehr große Anzahl an virtuellen Feldgeräten in einem Ethernet-Segment erreicht werden. Somit kann eine Lastverteilung realisiert werden, wodurch dynamisch auf normale Schwankungen in den Anforderungen der Applikation eingegangen werden kann, ohne weitere Ressourcen präventiv zu allokieren.

Die so geschaffenen virtuellen Feldgeräte können in einem Testszenario neben den realen Geräten integriert und verwendet werden. Ein vereinfachter Beispielaufbau hierzu ist in Bild 2 zu sehen. Dieser Beispielaufbau realisiert die Integration einer realen Steuerung und eines realen Feldgeräts und drei angeschlossenen virtuellen Hosts, auf denen je ein Generic Device ausgeführt wird. Die Datenpakete auf dem Netzwerk – dargestellt in Bild 2 mit den eingefärbten Vierecken – werden durch die Bridge den einzelnen Generic Devices zugeordnet. Für den Feldbuscontroller der Steuerung ist es nicht relevant, ob sie mit virtuellen oder realen Geräten kommuniziert, da beide Feldgerätearten für die Steuerung transparent sind. Unter der Zuhilfe­nahme einer Virtualisierungslösung ist es somit möglich, Software-Feldgeräte, die Prototypen für später zu installierende Feldgeräte sind, sehr einfach in einer nahezu beliebigen Anzahl zu erstellen und für den Test der Leitsystemapplikation bereitzustellen.