Die Entwicklung der applikativen Gerätesoftware von Feldgeräten erfolgt häufig auf der Grundlage bewährter Kommunikations-Stacks, so dass eine funktionsfähige Kommunikationsanschaltung bis zum Data Link Layer entsprechend dem OSI-Referenzmodell vorliegt. Für den Bereich der embedded Software wurde in den letzten Jahren eine Vielzahl von Werkzeugen entwickelt. Der Einsatz dieser Werkzeuge ist mit Investitionen verbunden beziehungsweise setzt spezielles Know-how voraus, das vor allem bei kleineren Geräteherstellern nicht immer vorhanden ist.

In der Summe bleibt der Zugriff auf die Hardware- Ressourcen des Feldgerätes immer noch relativ umständlich. Die mit den Fortschritten der Hardware möglichen Ausweitungen der Gerätesoftware führen auf der anderen Seite auch zu einer deutlich gesteigerten Komplexität der Software. Hinzu kommt: Mittlerweile wird kaum noch Gerätesoftware von einer einzelnen Person erstellt. Ergo gilt es, komplette Software-Projekte aufzusetzen, in denen „strenge" Regeln einzuhalten sind.

Das heißt: Das Software-Projekt wird in entsprechende Phasen unterteilt, in denen Anforderungs-, Pflichtenhefte sowie Design- und Testspezifikationen zu erarbeiten sind. Alles in allem ein komplexer Prozess, der zwar im Wesentlichen recht ausgereift ist, jedoch einen erheblichen Zeitaufwand bedeutet - insbesondere was die Einbindung der Sensoren und das Ansprechen der Aktoren sowie die Entwicklung und Inbetriebnahme des applikativen Teils der Gerätesoftware betrifft.

Entscheidende Einsparungen lassen sich hier erreichen, indem wichtige Teile der Geräte-Applikation, die zum Großteil aus logischen Verknüpfungen und Berechnungen besteht, in einer Umgebung entwickelt werden, in der alle modernen Hilfsmittel wie Debugger und Profiler einsetzbar sind. Es hat sich nämlich gezeigt, dass sich der Zugriff auf die eigentlichen Sensoren/Aktoren sehr gut kapseln lässt, so dass diese wie Treiber gehandhabt werden können.

Transparente Kommunikation

Das folgende Szenario der Applikationsentwicklung für neue Profibus- oder auch Profinet-Feldgeräte soll aufzeigen, wie sich die Geräte-Applikation mit dem realen Feldbus-System verbinden lässt, um das Kommunikationsverhalten des Gerätes zu implementieren. Um auch in dieser Entwicklungsphase noch unabhängig von der realen Hardware zu bleiben, bieten sich entweder Emulationen oder die Möglichkeit der Feldbus-Substitution an. Notwendig dazu ist eine bestehende, generische Kommunikationsanschaltung, die alle Feldbus-Dienste transparent weitergibt, um diese in der eigenen Geräteapplikation verarbeiten zu können.

Beispiel für die Nutzung eines „virtuellen Feldgerätes

© Fujitsu, ifak

Ein Beispiel für eine solche generische Kommunikationsanschaltung ist das Profilgate- Gerät (siehe Bild oben, Mitte), welches vom Institut für Automation und Kommunikation (ifak) Magdeburg zur prototypischen Geräteanwendungs-Entwicklungen für verschiedene Feldbus-Protokolle entwickelt wurde. Diese Anschaltung kam erstmalig im Rahmen der Profil-Entwicklung für die I&M-Funktionen (Identification & Maintenance) der Profibus-Nutzerorganisation zum Einsatz. Mit den I&M-Funktionen wurden für Profibus einheitliche Datenstrukturen (I&M-Daten) und Zugriffsmechanismen definiert, damit Applikationen unabhängig von Gerätetyp und -profil auf diese Informationen zugreifen können. I&M-Daten lassen sich sowohl geräteglobal, als auch für einzelne Module eines Gerätes hinterlegen.

Ergebnis dieser Entwicklung war ein portierbares I&MSoftwaremodul, das getestet ist und in den Profibus-Geräten verschiedener Hersteller als Bibliotheks-Element einsetzbar ist. Mit der Entwicklung eines Systems zum Test Profisafe-konformer, sicherheitsgerichteter Hosts (F-Hosts) ergaben sich neue Anforderungen an eine Hardware-Anschaltung für die Kommunikation. Dementsprechend hat das ifak die vorhandene Profilgate- Basis in der aktuellen Version 4.0 dahingehend erweitert, dass neben Profibus nun Profinet sowie notwendige binäre Output- Operationen unterstützt werden.

Die überarbeitete Software-Schnittstelle zeichnet sich jetzt dadurch aus, dass alle darunter liegenden Hardware-Anschaltungen über die gleiche Abstraktionsschicht ansprechbar sind. Applikationen, die direkt auf dem Profilgate ablaufen sollen, nutzen ausschließlich diesesAPI (Application Programming Interface).

Aus Sicht einer vereinfachten Applikationserstellung, um zum Beispiel neue Feldbus-Profile zu testen, lässt sich diese Applikation auf einem abgesetzten PC abarbeiten. Die Kommunikation zwischen der generischen Kommunikationsanschaltung und dem PC erfolgt über eine normale Ethernet-TCP/IP-Verbindung. Das darauf ablaufende Übertragungsprotokoll (RFC - Remote Function Call) wurde dahingehend optimiert, dass die durch das Profilgate-Gerät angebotene Softwareschnittstelle exakt abgebildet wird.

Exakt heißt, dass es im RFC je API-Funktion einen Dienst gibt. Eine weitere Vereinfachung für den Nutzer stellt die Kapselung der RFC-Client-Funktionalität in einer Bibliothek dar, wobei darin das komplette RFC-Protokoll gehandhabt wird und die Schnittstelle der der embedded API entspricht. Die Bibliothek ist für mehrere Betriebssysteme prozessorunabhängig verfügbar.

Debuggen - eine zeitaufwändige Maßnahme

Die für das Endgerät gewünschte hohe Softwarequalität lässt sich bei der aufgezeigten Entwicklungsmöglichkeit sehr gut bestimmen beziehungsweise die Entwickler können ihre Software leicht - zum Beispiel ohne Emulatoren - untersuchen. Zeitaufwendig ist das Debuggen, gerade wenn nebenläufige Algorithmen untersucht werden müssen, um beispielsweise Synchronisationsprobleme aufzuspüren und zu eliminieren.

PC-basierte Debugger bieten heute in der Regel sehr ausgefeilte Eigenschaften wie Watches oder Tracing, so dass auf das umständliche Erstellen von Logging-Ausgaben zur Fehlereinkreisung weitgehend verzichtet werden kann. Ein weiterer Aspekt ist die Optimierung der Gerätesoftware, in deren Rahmen die Laufzeiteigenschaften der Algorithmen untersucht werden. Hierfür kommen so genannte Profiler zum Einsatz, die meist im Top-down-Verfahren die benötigten Laufzeiten der Module/ Prozeduren oder deren Aktivierungshäufigkeiten auflisten.

Die Software-Struktur im Profilgate V4.0: Dargestellt sind der interne Aufbau und die Einbindung in PC-basierte Applikationen über eine Bibliothek mit C-API.

© Fujitsu, ifak

Der Einsatz dieser Art von Werkzeugen setzt voraus, dass die erstellte Software auch stimuliert wird. Im betrachteten Einsatzfall der Feldbus-Substitution kommen die Stimuli entweder vom Feldbus-System oder die Gerätesoftware selbst muss ebenfalls aktiv abgearbeitet werden. Vor derAbarbeitung der kompletten Applikation sollten jedoch Überprüfungen der einzelnen Module in Form von Unit-Tests durchgeführt werden.

Hierfür steht wiederum eine Vielzahl von Werkzeugen zur Verfügung. Der Unit-Test zielt darauf ab, Fehler in der Software zu finden, solange noch einzelne Module betrachtet werden. Dazu gilt es, modulspezifisch Sollwerte vorzugeben und mit den beim Test ermittelten Istwerten zu vergleichen. Diese Tests lassen sich ebenfalls sehr gut automatisieren und für Regressionstests einsetzen, die zum Beispiel beim automatischen Erstellungsprozess abgearbeitet werden. Ein nicht zu unterschätzender Vorteil der Entwicklung der Geräte-Applikation auf einem PC ist der Einsatz mehrerer unterschiedlicher Compiler. Allerdings gibt es noch keinen perfekten, also fehlerfrei arbeitenden Compiler.

Daher ist die Wahrscheinlichkeit, eigene Fehler in der Geräte-Applikation zu finden, beim Einsatz diversitärer Werkzeuge wesentlich größer, was wiederum der Softwarequalität zugute kommt. Unter dem Strich lässt sich festhalten: Die im Artikel aufgezeigte Möglichkeit, Geräte-Applikationen in einer einfacher zu handhabenden Umgebung zu entwickeln und zu testen, kann kostensenkend wirken.

Dies gilt auch mit Blick auf das Forschungsfeld der „Digitalen Fabrik", bei der die schrittweise reale Inbetriebnahme der Produktionsanlage ein wesentliches Szenario darstellt. Eine generische Kommunikationsanschaltung wie Profilgate könnte hier ihr Potenzial ausspielen, indem sich die gleiche Hardware für verschiedene Verhaltensweisen konfigurieren lässt, ohne dass die realen Geräte bereits vorhanden beziehungsweise installiert sein müssen.

Bis die Vision der kompletten virtuellen Inbetriebnahme verwirklicht ist, sind jedoch noch einige Anstrengungen zu unternehmen, um die Vielzahl der Geräte-Applikationen so aufzubereiten, dass sie in einer emulierten Umgebung abgearbeitet werden können.

Autor: Dr. Matthias Riedl ist Leiter des Bereiches Informationsmanagement für Umwelt & Automation am Institut für Automation und Kommunikation Magdeburg.