In der Prozess- und Automatisierungsindustrie wurden bis vor einigen Jahren die jeweiligen Geräte mit speziell dafür geschriebener Software ausgeliefert. Je mehr Geräte die unterschiedlichen Firmen einsetzten, desto mehr Anwendungen musste der Benutzer installieren und auch beherrschen, um die gewünschten Einstellungen vornehmen zu können.
Diese Defizite erkannte die FDT Group. Seit einigen Jahren gibt es FDT (Field Device Tool), das eine Plugin-Schnittstelle für Anwendungen der Automatisierungstechnik definiert. Den Rahmen stellt die grundsätzliche Anwendung dar, die durch Plugins, so genannte DTMs (Device Type Manager), erweitert werden kann. Dadurch findet eine Trennung der Zuständigkeiten statt: die Rahmenanwendung stellt die Benutzeroberfläche dar und legt fest, wie die Plugins angesprochen werden. Für jede anzusprechende Geräteklasse wird ein DTM installiert. So braucht der Benutzer sich nur noch in einer Anwendung auszukennen und kann dank DTMs auf Geräte aller Arten zugreifen. Die Plugin-Schnittstellen erlauben zwei außerordentlich leistungsfähige Mechanismen: mehrere DTMs können zusammenarbeiten und über mehrere Protokollebenen (zum Beispiel Hart über Profibus über Ethernet) hinweg kommunizieren. Weiter kann ein DTM eine oder mehrere grafische Benutzerschnittstelle bereitstellen, um spezielle Aufgaben zu erfüllen. Genau dieser mächtige Lösungsansatz birgt jedoch auch Tücken: zum einen müssen plötzlich Komponenten verschiedener Hersteller miteinander zusammenarbeiten, wo früher die einer einzelnen Firma den reibungslosen Betrieb sicherstellen konnte. Zum anderen handelte man sich über die frei gestaltbare Benutzerschnittstelle einen Teil der Probleme wieder ein, die man ursprünglich zu lösen versuchte.
Plugins unter Beschuss
Für den reibungslosen Betrieb mehrerer DTMs untereinander und auch in der Rahmenanwendung sorgt der dtmInspector. Dieses offizielle Test-Tool der FDT-Group stellt 270 Tests für DTMs bereit, um das Einhalten der Spezifikationsregeln an den Plugin-Schnittstellen zu prüfen. Die Tests reichen dabei von der Installation bis zur Entfernung des DTMs vom System.
Diese umfangreiche Testsuite ist ein wichtiger Bestandteil der regelmäßigen Tests, die ein DTM-Entwickler mit seinem DTM durchführt. Zudem erlaubt der dtmInspector im Gegensatz zu frei verfügbaren Rahmenanwendungen viele Tests, die sonst nur mit Mühe zu erreichen sind. In frei verfügbaren Rahmenanwendungen sind Benutzer meist als Administrator angemeldet. Die Ausführung eines DTMs mit eingeschränkten Rechten wird möglicherweise gar nicht unterstützt oder bleibt oft einfach unbemerkt. DtmInspector geht alle in FDT verfügbaren Benutzer durch und untersucht, ob sich der DTM auch dann noch korrekt verhält. Hauptanwendung von kostenfreien Rahmenanwendungen sind häufig mobile Installationen auf einem Laptop, zum Durchführen von Diagnosen. Hier ist es nicht nötig, Informationen zwischen mehreren Teilen auszutauschen, wie es bei einem DCS (Distributed Control System) erforderlich ist. DtmInspector testet auch den Datenexport über die IDtmImportExport Schnittstelle, die man in einem solchen System zum Datenaustausch zwischen Teilsystemen verwendet. Unter dem gleichen Hintergrund überprüft dtmInspector auch das Verhalten des DTM in einem (simulierten) Mehrbenutzer-System. Es überprüft, ob eine Veränderung von Daten korrekt auf andere Rechner im Netzwerk übertragen werden kann, und dort zu einer korrekten Aktualisierung der Anzeige führt. Die Durchführung der Tests erfolgt automatisch, sofern keine Benutzereingaben erforderlich sind. Dadurch werden Befehle wesentlich schneller hintereinander an die DTMs gesandt, als das im normalen Betrieb bei Bedienung durch einen Benutzer der Fall ist. Der dtmInspector deckt dabei Fehler in der zeitlichen Abarbeitung auf, die in gleicher Weise im automatischen Betrieb in einer großen Anlage auftreten können. Im Normalfall zeigen sich Rahmenanwendungen fehlertolerant. Unter Umständen werden alternative Ausführungsmöglichkeiten in Betracht gezogen oder ein Befehl wiederholt, wenn ein Fehler zurückgegeben wird. DtmInspector lässt ein solches Verhalten nicht zu. Eine bereitgestellte Funktion muss auf Anhieb funktionieren. Im Zusammenspiel von mehreren DTMs müssen Rückgabewerte von anderen DTMs richtig ausgewertet werden. Fehlermeldungen muss man berücksichtigen und korrekt analysieren. Von den möglichen Fehlersituationen können von einem Entwickler nur wenige nachgestellt werden, etwa durch Ausstecken des Kabels. DtmInspector kann jedoch direkt in die Kommunikation zwischen zwei Plugins eingreifen und alle Fehlerwerte simulieren. Die meisten verfügbaren Rahmenanwendungen implementieren alle Plugin-Schnittstellen. Ob ein DTM auch funktioniert, wenn optionale Schnittstellen nicht verfügbar sind, findet ein Entwickler ebenfalls mit dtmInspector heraus. Eine weitere Besonderheit bietet dtmInspector beim Test auf private Dialoge. Speziell in größeren Anlagen ist es strikt verboten, Dialoge außerhalb eines definierten Bereichs zu öffnen, um zu verhindern, dass etwa Alarmmeldungen verdeckt werden. Die Installation und Deinstallation lassen Entwicklern häufig außer Acht, während sie die üblichen Tests schon häufiger durchführen. DtmInspector zwingt die Entwickler, auch diese Tests durchzuführen. Dabei wird überprüft, ob der DTM sich selbst korrekt registriert, damit die Rahmenanwendung das Plugin auch finden und laden kann. Nach 270 Tests, die auf Wunsch auch einzeln angesprochen werden können, gibt dtmInspector das Ergebnis aus. Der äußerst ausführliche Testreport zeigt, wann welche Methoden aufgerufen wurden und welches Ergebnis sie zurückgegeben haben. Der Testreport ist das maßgebliche Dokument für die Ausstellung eines Zertifikats.
DTMs auf den Zahn fühlen
Einige der im dtmInspector enthaltenen Tests erfordern jedoch, dass der Benutzer Eingaben vornimmt: einmal sollen zugelassene Werte eingetippt und ein anderes Mal völlig abwegige Daten ausprobiert werden. Dabei sollte man auch alle verfügbaren Parameter wenigstens einmal untersuchen. Was jedoch an einer Stelle funktioniert, muss sich an einer anderen Stelle nicht zwingend gleich verhalten. Außerdem kann etwas auf einer Entwicklermaschine laufen, aber noch lange nicht auf einem anderen PC.
Hier baut die FDT Group auf ihren Zertifizierungsprozess. Dieser Prozess sieht vor, dass die Ausgabe eines Testreports, der zur Zertifizierung führt, nur von einem auditierten und akkreditierten Testlabor durchgeführt wird. Das Testlabor muss gegenüber der FDT Group vorweisen, dass es FDT Know-How besitzt und dem definierten Prozess zur Überprüfung von DTMs folgt. Auch Kenntnis mit dem Umgang von Automatisierungs- und Prozess-Hardware sind nachzuweisen. Ein Auditor, der sich vor Ort von der Qualifikation des Testlabors überzeugt hat, bescheinigt ihm auch die Unabhängigkeit von finanziellen Einflüssen oder firmeninternen Hierarchien. Ein DTM kann bei einem Testlabor für eine unabhängige Überprüfung eingereicht werden. Der Test läuft auf einem frisch installierten System ab, um sicherzustellen, dass der DTM keine Dateien benötigt, die sonst nicht verfügbar sind. Sollten man etwa zur Kommunikation weitere DTMs benötigen, kommen bei diesem Test nur weitere bereits zertifizierte Komponenten zum Einsatz. Hat der Entwickler den DTM erfolgreich und ordnungsgemäß geprüft, stellt auch das Testlabor keine Fehler mehr fest. Sollten wider Erwarten Fehler gefunden werden, muss nachgebessert und der Test wiederholt werden. War der Test erfolgreich, erhält der DTM ein formelles Zertifikat in Papierform und darf sich mit dem „FDT certified“ Logo schmücken. Außerdem ist der DTM auf der FDT Group Webseite für zertifizierte DTMs veröffentlicht.
Geregelte Darstellung hilft Fehler zu vermeiden
Um die grafischen Oberflächen von DTMs einfach zu erlernen und einheitlich zu gestalten, wurde der DTM-Styleguide entwickelt. Dieser definiert Grundsätze und Regeln, nach denen eine Bedieneroberfläche aufgebaut sein muss.
Damit der Benutzer weiß, bei welchem Gerät er gerade Parameter ändert oder Einstellungen vornimmt, gibt die Identification Area Auskunft. Dort befindet sich der Name des Herstellers und der Gerättyp, dessen Seriennummer und Firmware-Version. Direkt darunter kann der Benutzer häufige Funktionen über eine Symbolleiste aufrufen. Wie auch schon bei Webseiten, hat sich der linke Bereich als Navigationsbereich bewährt. In einer ausblendbaren Baumansicht kann sich der Benutzer strukturiert durch die Einstellmöglichkeiten bewegen. Im größten Bereich findet dann die eigentliche Einstellung statt. Hier kommen häufig Eingabefelder zum Einsatz, die dann mit den definierten Symbolen für gültige Änderungen, ungültige Eingaben oder in Abhängigkeit geänderte Werte gekennzeichnet werden. Komplexere Eingabeelemente wie etwa eine grafische Eingabe einer Linearisierungskurve unterliegen jedoch keiner Restriktion. Für die Übernahme oder die Verwerfung der eingegebenen Werte dient eine eigene Region, die mit entsprechenden Schaltflächen bestückt ist. In der direkt darunter angeordneten Statuszeile kann der Benutzer erkennen, ob gerade eine Verbindung mit dem Gerät besteht, ob der gesamte Datensatz gültig ist oder ob er überhaupt über die Rechte verfügt, Änderungen vorzunehmen. Außer der Anordnung der Objekte hat die FDT Group auch Verhalten definiert. So sollten sich alle Elemente auch per Tastatur erreichen lassen und sich generell so verhalten, wie der Benutzer das von anderen Windows-Anwendungen gewohnt ist. Auch die Farbgebung sollte sich dem vom Benutzer ausgewählten Farbschema anpassen – Firmenfarben sind höchstens in der Identifizierungsregion erwünscht. Neben der Styleguide-Spezifikation stellt die FDT Group eine Checkliste zur Verfügung, anhand der ein Entwickler die Konformität zur Spezifikation genauer erfassen kann. Wie auch bei der Konformität zur technischen Spezifikation, wird für die Ausstellung eines Zertifikats die Hilfe eines unabhängigen Testlabors benötigt. Das Testlabor prüft ebenfalls anhand der Checkliste, ob der DTM alle Anforderungen erfüllt.
DTMs stehen im Mittelpunkt
Während bisher nur DTMs mit einem offiziellen Tool getestet wurden, konnte man Hersteller von Rahmenanwendungen nicht mit offiziellen Tests beliefern. 2007 entschied sich die FDT Group, auch den umgekehrten Weg einzuschlagen. Zukünftig werden auch Rahmenanwendungen überprüft, ob sie korrekt mit den DTMs umgehen.
Vorschläge für eine Architektur wurden bereits unterbreitet und Tests definiert. Die Testumgebung wird hier selbst ein DTM sein, der zu Protokollierungszwecken eine Verbindung zu seiner Steueranwendung aufbaut. Der Test-DTM wird Übergabeparameter an die Steueranwendung weiterleiten, die sie auf Korrektheit überprüfen. Bricht die Verbindung zwischen DTM und Steueranwendung unerwartet ab, bewertet das Steuerprogramm dies negativ, da ein Plugin nach definierten Mechanismen beendet werden muss. Im Gegensatz zu dtmInspector werden bei der Testumgebung (frameInspector) Tests möglicherweise mehrfach ausgeführt, abhängig davon, wie viele verschiedene Möglichkeiten es gibt, eine Aktion auszuführen. Kann ein DTM auf zwei Arten in ein Netzwerk eingefügt werden, etwa per Drag’n’Drop oder per Auswahl aus einer Liste, so ist der Test für das korrekte Einfügen zwei Mal durchzuführen – der zugrunde liegende Code muss ja nicht zwangsläufig der gleiche sein.
Bereit für die Zukunft
Die FDT Group hat es geschafft, durch eine neue Technologie Probleme der Prozess- und Automatisierungsindustrie zu lösen. Auf die beiden dadurch neu entstandenen Risiken nahm man frühzeitig Einfluss: DtmInspector stellt seit 2004 die Konformität der DTMs zur Spezifikation sicher und der DTM-Styleguide sorgt für eine einheitliche Bedienung von Oberflächen unterschiedlicher Hersteller. Der definierte Prozess der unabhängigen Zertifizierung beweist das auch gegenüber Endbenutzern. Der Endbenutzer erkennt am „FDT certified“ Logo einen korrekt arbeitenden DTM.
DTMs müssen auch den aktuellen und zukünftigen Entwicklungen folgen. Aus diesem Grund wurde dtmInspector erweitert, um DTMs auch unter Windows Vista testen zu können. Außerdem wird mit zertifizierten DTMs in regelmäßigen Abständen ein Interoperabilitätstest durchgeführt. Hier werden DTMs unterschiedlicher Hersteller und in unterschiedlichen Kombinationen in mehreren Rahmenanwendungen ausgeführt. Sollten wider Erwarten Probleme auftreten, so werden diese analysiert und neue Tests für dtmInspector definiert, damit der Fehler alle zukünftigen DTMs nicht mehr betrifft. Während derzeit FDT 1.2 die am weitesten verbreitete Version ist, existiert bereits der Nachfolger FDT 1.2.1, der eine erweiterte Plugin-Schnittstelle liefert. DtmInspector wurde um Tests für diese FDT-Version ergänzt, damit DTMs nach der neuen Version gleich von Anfang an von umfangreichen Tests profitieren können. Ab 2009 existieren auch offiziell vorgegebene Tests, die überprüfen, ob eine Rahmenanwendung korrekt mit DTMs umgeht. Dann könnten erstmals auch die Programme das „FDT certified“ Logo erhalten.
Dieser Beitrag als PDF und weiterführende Informationen (ähnliche Beiträge, technische Daten, Direktlinks zum Hersteller etc.) sind online verfügbar auf www.PuA24.net
• more@click-Code: PAK80139
