Auf einen Nenner gebracht

Sandra Gisy, Markus Schade, Joachim Tschampel und Thomas Westers

FDT basiert auf der Interaktion zweier Arten von Softwarekomponenten, den Device Type Manager (DTM) und der Rahmenapplikation, häufig auch mit Frame oder Container bezeichnet.

Der DTM ist ein Softwarebaustein, der inhaltlich ein bestimmtes Gerät oder eine Kommunikationskomponente mit ihren Eigenschaften und Funktionen einschließlich ihrer Bedienoberfläche repräsentiert. Ein Anwender kann diese mithilfe einer Rahmenapplikation aufrufen. Aus einer Rahmenapplikation heraus organisieren die DTMs den Umgang mit den zugehörigen Geräten und Kommunikationskomponenten in der Anlage. Ein DTM kann auch, einer gebräuchlichen Definition aus der Softwareentwicklung folgend, als Proxy (Stellvertreter) bezeichnet werden, der die Kontrolle über ein Objekt (hier die in der Anlage verteilten Geräte und Kommunikationskomponenten) auf ein vorgelagertes Objekt (hier die zentrale Rahmenapplikation) überträgt. Der DTM ist kein eigenständiges Programm, sondern benötigt zur Ausführung immer eine FDT-Rahmenapplikation.

Eine FDT-Rahmenapplikation ist ein Softwareprogramm, das DTMs implementiert und ihnen eine gemeinsame Ablaufumgebung mit der standardisierten FDT-Schnittstelle bietet. Rahmenapplikationen können in unterschiedlichen Systemumgebungen wie Konfigurations- oder Engineering-Tools, Bedienkonsolen oder Asset Management-Tools ausgeführt werden. Rahmenapplikationen werden von verschiedenen Herstellern bzw. Herstellergruppen entwickelt und gepflegt, Beispiele sind Pactware, FieldCare, FieldMate, fdtContainer u.a. Über die implementierten DTMs realisieren sie den Zugriff auf die Kommunikationskomponenten und Feldgeräte der Anlage mit ihren Parametern, Messwerten, Diagnosemeldungen, Statusinformationen sowie Funktionen, die die DTMs ggf. zusätzlich zur Verfügung stellen. Alle zu einer Anlage bzw. ihren Komponenten gehörigen DTMs stehen automatisch nach Ihrer Installation in der Rahmenapplikation im Gerätekatalog zur Verfügung.

Entsprechend ihrer funktionellen Zuordnung unterscheidet man zwischen Geräte-DTMs und Kommunikations-DTMs (Bild 1).

Geräte-DTMs dienen zum Management von Geräten. Sie sind entsprechend geräte-orientiert aufgebaut und enthalten spezifische Daten, Funktionen und Logikelemente „ihres“ Gerätes. Der Inhalt eines DTM entspricht in der Regel dem Funktionsumfang des Gerätes, er kann diesen jedoch auch unterschreiten. Je nach Implementierungsgrad reicht ein DTM von einer einfachen grafischen Benutzerschnittstelle für das Einstellen der Geräteparameter bis zu zusätzlich programmierten, hochentwickelten Anwendungen, die z. B. umfangreiche Berechnungen für Diagnose- bzw. Wartungszwecke durchführen oder eine spezielle Logik zur Gerätekalibrierung abarbeiten können.

Im Gegensatz zu dieser inhaltlichen Gestaltungsfreiheit eines DTM ist seine Schnittstelle (basierend auf FDT) zur Rahmenapplikation verbindlich vorgeschrieben und sind für die Ausgestaltung der Benutzer-oberfläche die Vorgaben des DTM Style Guide verpflichtend.

Geräte-DTMs werden je nach ihrer Verwendung in Gruppen unterteilt (Bild 1, links):

Gerätespezifische DTMs

Sie unterstützen mindestens ein Gerät, können aber auch bestimmte gemeinsame Eigenschaften einer ganzen Gerätefamilie eines Herstellers unterstützen, z. B. eine Produktreihe von Druckmessumformern oder Füllstandsgeräten.

Die für ein Gerät speziell programmierten DTMs werden als dedizierte Geräte-DTMs bezeichnet. Sie repräsentieren die volle Gerätefunktionalität und können mit weiterführenden Funktionen wie z. B. Netzwerk-Diagnose oder Verlauf-Darstellungen (Bild 4) ausgebaut werden, bis hin zum Leistungsumfang eines eigenständigen Tools.

In Abgrenzung dazu sind die Interpreter-DTMs zu sehen, die zwar auch gerätespezifisch sind, jedoch nicht speziell für ein bestimmtes Gerät programmiert wurden, sondern durch Interpretation einer vorhandenen Gerätebeschreibung (DD) entstehen. Sie verfügen auch über einen eigenen Eintrag im Gerätekatalog der Rahmenapplikation, sind allerdings in der Regel grafisch weniger aufbereitet als Geräte-DTMs. Ein Beispiel hierfür ist der IO-DD-Interpreter-DTM, der die DDs von IO-Link-Geräten interpretiert und mit dessen Hilfe IO-Link-Geräte parametriert werden können.

Universelle (generische) DTMs

Sie vertreten nicht ein Gerät oder eine Gerätegruppe eines Herstellers, sondern Gemeinsamkeiten von Geräten verschiedener Hersteller. Hierzu gehören die protokoll-konformen Parameter, die für alle Geräte einer Protokollklasse (Hart-Geräte, Profibus-PA-Geräte) übereinstimmen und daher in einem einzigen DTM beschrieben werden können. Bei einem generischen Hart-DTM z. B. sind das die Parameter, die über den Begriff „Universelle und die Standard-Kommandos“ (Universal und Common Practice Commands) erreichbar sind. Bei einem generischen Profibus-Profil-DTM betrifft das alle Profilparameter eines Feldgerätes.

Generische DTMs verfügen über nur einen Eintrag im Gerätekatalog der Rahmenapplikation.

Geräte-DTMs werden in der Regel vom Gerätehersteller entwickelt und als Teil des Lieferumfangs bereitgestellt. Zusätzlich bieten Dienstleister vornehmlich universelle DTMs an, jedoch auch spezifische von Geräten, für die der Hersteller keine DTMs entwickelt hat.

Kommunikations-DTMs (Bild 1, rechts) enthalten alle Funktionen und Dialoge für die Verwaltung und Konfiguration der jeweiligen kommunikationsspezifischen Baugruppen. Sie ermöglichen der zentralen FDT-Rahmenapplikation den Zugriff auf die Kommunikationskomponenten der Geräte, wie Schnittstellenkarten, Gateways oder Koppler.

Damit dienen sie den Geräte-DTMs als Kommunikationskanal zu den zugeordneten Geräten. In diesem Kontext werden auch die spezifischen Eigenschaften eines Feldbusses (z. B. Profibus oder Foundation Fieldbus) durch CommDTMs repräsentiert.

Entsprechend ihrer Funktion werden bei den Kommunikations-DTMs technisch zwei Gruppen unterschieden, die jedoch aus Gründen einer vereinfachten Darstellung häufig auch beide mit dem Überbegriff CommDTMs bezeichnet werden.

Alle für den Zugriff auf die Anlagenkomponenten erforderlichen DTMs sind im Gerätekatalog der Rahmenapplikation implementiert. Für den Zugriff auf die Anlage werden diejenigen DTMs aufgerufen und miteinander verkoppelt, die dem gewünschten Zugriffsweg entsprechen (Bild 2). Dabei benötigt ein Geräte-DTM immer mindestens einen Kommunikations-DTM als Kanalöffner, um auf sein Feldgerät zuzugreifen. Mit den entsprechenden Gateway-DTMs ist die Rahmenapplikation in der Lage, Kommunikationspfade auch über Protokollstufen hinweg zu öffnen. Es gibt heute Gateway-DTMs für alle gängigen Kommunikationsprotokolle, für weitere Protokolle und zugehörige Komponenten sind DTMs erstellbar. Das wird erheblich vereinfacht durch die Fähigkeit der Rahmenapplikation, bei geöffnetem Kommunikationspfad die angeschlossenen Geräte scannen und die richtigen DTMs zuordnen zu können.

Eine für alle DTMs aller Hersteller einheitlich und übersichtlich gestaltete grafische Oberfläche trägt sehr viel zu einer leicht erlernbaren und bezüglich Fehlbedienung risikoarmen Handhabung bei. Dafür wurde der DTM Style Guide definiert, der die Regeln für den Aufbau (Look&Feel) der Bedienoberfläche festlegt. Der Style Guide definiert für Geräte-DTM und Kommunikations-DTM eine einheitliche, skalierbare Bedienoberfläche (Bild 3) mit festgelegten Bereichen.

Für die Erstellung von DTMs gibt es verschiedene Vorgehensweisen:

Der DTM für ein bestimmtes Gerät wird durch den Gerätehersteller oder einen Dienstleister unter Beachtung der FDT-Vorgaben (FDT-Spezifikation und DTM Style Guide) von Grund auf neu programmiert. Es entsteht ein eigenständiger DTM, der sämtliche Funktionen und Eigenschaften des Gerätes unterstützt. Dieser DTM gleicht damit einer komplett programmierten Software, gekoppelt mit dem zusätzlichen Vorteil einer Standardschnittstelle, mit der er problemlos in andere Systeme integriert werden kann.

Der DTM für ein bestimmtes Gerät wird aus einer für das Gerät bereits vorhandenen Gerätebeschreibung (DD) durch Extraktion der gespeicherten Informationen und Transformation auf die FDT-Schnittstelle erzeugt. Es entsteht ein eigenständiger Basis-DTM im Funktionsumfang der transformierten Gerätebeschreibung. Soll der DTM noch darüber hinausgehende Funktionen beinhalten, so ist eine Weiterentwicklung der DTM-Software möglich, wofür es Unterstützungstools gibt. Das Resultat ist wieder ein eigenständiger DTM.

Allgemein gültige Funktionsinhalte einer Gerätebeschreibung werden durch einen Interpreter-DTM interpretiert und an die FDT-Schnittstelle transformiert. Diese Interpreter-DTMs verhalten sich in der Rahmenapplikation wie normale DTMs. Eine Weiterentwicklung findet hier nicht statt. Ein Beispiel hierfür ist der iDTM-Hart (interpreter Device Type Manager), der Hart-DDs/EDDs interpretiert und die Einbindung von Hart-Geräten beliebiger Hersteller ermöglicht, für die es keinen DTM gibt. Er basiert auf einem EDD-Interpreter (Electronic Device Description) der Hart Communication Foundation (HCF) und enthält über 600 registrierte Hart-EDDs der HCF-Bibliothek, die regelmäßig aktualisiert wird. Diese Vorgehensweise ist herstellerunabhängig. Generische DTM, die Gemeinsamkeiten von Protokollen bzw. Profilen repräsentieren und ebenfalls herstellerunabhängig sind, werden in der Regel von Dienstleistern entwickelt und vermarktet. Ein Beispiel hierfür ist der Generic Hart-DTM von ICS (Bild 3, unten).

Device Type Manager erleichtert die Arbeit mit Feldgeräten, da keine speziellen Kenntnisse über die verwendeten Bussysteme und deren Kommunikationsprotokolle zwischen Bedienerarbeitsplatz und dem Feld benötigt werden. Alle Geräte präsentieren sich in der gleichen Art und Weise, unabhängig, ob es sich um gerätespezifische oder generische DTM handelt. Dadurch ist eine intuitive und leichte Handhabung der Geräte und ihrer Konfiguration mittels DTM möglich. Die mittels DTMs durchgeführten spezifischen Gerätekonfigurationen werden in der FDT-Rahmenapplikation abgespeichert und erlauben somit ein zentrales Datenmanagement. FDT ist durch seine Offenheit zukunftssicher und von dem Endanwender ohne spezielles Fachwissen einsetzbar.

Online-Info www.cav.de/0810405