Knapp acht Jahre hat es gedauert. Nun ist es geschafft. Das Beste aus EDDL (Electronic Device Description Language) und FDT (Field Device Tool) ist in einer neuen Technologie vereint, ergänzt um neue Konzepte, die Mehrwert schaffen. Das standardisierte und zentrale Datenmodell für Gerätedaten über OPC UA und das Lebenszykluskonzept sind Beispiele dafür. Außerdem entstand eine leistungsstarke Entwicklungsumgebung für Gerätehersteller, die FDI Package IDE. Für Leitsystemhersteller, die ihr Produkt nativ mit FDI ausstatten wollen, wurde das spezifizierte Verhalten eines FDI Hosts in die FDI Common Host Components implementiert.
Die Ziele: Vereinheitlichung, Vereinfachung, Kostenminimierung (insbesondere auf Seiten der Gerätehersteller und Anwender) sowie drastische Reduktion der immer wieder auftretenden Interoperabilitätsprobleme. Das Ergebnis: Da ist sie nun, die „eine“ Integrationstechnologie. Die Hersteller, die gemeinschaftlich an der Technologie gearbeitet haben, feierten den Abschluss des FDI-Projekts. Die Veröffentlichungen der letzten Jahre loben FDI und seine technologischen Details, aber auch die kooperative Technologieentwicklung.
Müssen wir das Bestehende über Bord werfen?
Der Markt wartet nun auf Produkte, die FDI unterstützen. Die ersten Schritte sind beispielsweise von ABB mit der Veröffentlichung des Field Information Managers (FIM) gemacht worden. Bei all dem gespannten Warten entstand aber auch früh die Dualität: Vorfreude auf die Innovation FDI und die ernstzunehmende Frage: „Aber was passiert denn nun mit meinen existierenden Gerätemanagement-, Asset-Management- und Geräte-Analyse-Lösungen?“.
Ein Kernelement von FDI ist die binäre EDD, verpackt in ein FDI Package und konsumiert vom FDI Host. Für EDDL-basierte Produkte scheint FDI demnach ein logischer, evolutionärer Schritt zu sein, den die jeweiligen Host-Hersteller wohl durch eine clevere Produkt-Upgrade-Politik gehen werden. Siemens hatte auf der Namur-Hauptsitzung 2013 bereits einen Prototypen von PDM (Process Device Manager) vorgestellt, der sowohl die Nutzung von EDDs als auch FDI Device Packages gestattet. Hier gilt: Innovation und Investitionsschutz sind kein Widerspruch.
Für Systemhersteller und Anlagenbetreiber, die sich für FDT als Integrationstechnologie entschieden haben, stellt sich der Pfad in die FDI-Welt zunächst unebener und kurviger dar. Das liegt in den beiden Technologien EDDL und FDT begründet, die sich trotz funktionaler Ähnlichkeit in ihrem Ansatz sehr stark unterscheiden.
Wie umgehen Anlagenbetreiber Stolpersteine?
Während die Gerätebeschreibungssprache EDDL einen Weg standardisiert hat, mit dem man unterschiedliche Gerätemodelle und den Zugriff auf die Geräteparameter beschreiben kann (standardisierte domänenspezifische Sprache, Gerätetyp-Integration), löste FDT das Problem der Integration gerätespezifischer Software-Applikationen in ein übergeordnetes System (standardisierte Software-Schnittstellen, Software-Integration). Die Erweiterung eines FDT Hosts um FDI-Fähigkeiten ist somit durch ein einfaches Produkt-Upgrade nur schwer oder gar nicht zu erreichen.
Die Herausforderung ist nun, auch für die Hersteller und Anwender von FDT-basierten Produkten, eine einfache Möglichkeit bereitzustellen, FDI in ihr Anlagenleben zu integrieren. Dabei wird erwartet, dass Anwender zeitnah eine Lösung bei ihren Systemlieferanten erfragen werden, um sofort von der vereinheitlichten Welt profitieren zu können und eben nicht mehr prüfen zu müssen, ob das Gerät nun mit einem funktionierenden DTM ausgeliefert wird oder nicht. Systemlieferanten wollen insbesondere ihren langjährigen Bestandskunden eine FDI-Erweiterung anbieten können. Das ist ihr Anspruch. Natürlich kosteneffizient, unkompliziert und ungefährlich für die existierende Installation.
In der Welt der Stecker und Kabel lässt sich solch ein Anspruch an die Beherrschung von Technologie-Kombinatorik über simple Adapter beherrschen. Was nicht passt, wird eben passend gemacht. In der Welt der Software ist das auch möglich, allerdings weniger trivial. Die Einfachheit des Ergebnisses, nämlich die Umsetzung von einer Technologie auf eine andere, versteckt die hohe Komplexität im Inneren des Softwareprodukts.
Wie alte und neue Welt verknüpfen?
Für einen „FDI-nach-FDT-Adapter“ muss somit ein Geräte-DTM implementiert werden, der einen vollständigen FDI Host in sich trägt und selbstverständlich dem FDT-Standard entspricht. Der FDI Host ist dafür verantwortlich, das FDI Device Package zu konsumieren, den Gerätedatensatz konsistent zu halten, User Interface Descriptions (UID) zu rendern und User Interface Plug-ins (UIP) zu laden. Der DTM und der FDT Frame kümmern sich um das Management des Gerätedatensatzes und dessen Persistenz, aber auch um die Kommunikation mit dem physikalischen Gerät und das Hosting der Benutzeroberflächen. Idealerweise gibt es am Ende für jedes spezifizierte FDT Interface einen Kanal in die FDI-Welt. Zusätzlich ist der DTM zertifizierbar.
Ebenso wichtig ist, dass sich der DTM wie gewohnt installieren und nutzen lässt und keine Interoperabilitätsprobleme auf der FDT- oder der FDI-Seite auftreten. Um eben diese Gefahr zu bannen, werden bestenfalls zentrale Software-Komponenten eingesetzt. Die FDT Group stellt die DTM Common Components zur Entwicklung von Geräte-DTMs bereit (DTM-CC, für FDT2) und die FieldComm Group ihrerseits die FDI Common Host Components (EDD Engine – zur Interpretation von EDDL Code im Common Binary Format, UI Engine – zum Rendering der User Interface Description und zum Hosting von User Interface Plug-ins). Diese zentralen Komponenten, angereichert mit einer gehörigen Portion Erfahrung mit den Technologien, ihren Implementierungsdetails und mit den Anforderungen der Prozessindustrie, ergeben den perfekten „FDI-nach-FDT-Adapter“.
Ein Adapter kann dem Anwender potenziell von mehreren Seiten bereitgestellt werden. Der FDI-Adapter des System-Lieferanten würde, einmal installiert, die Integration von FDI Device Packages unterschiedlicher Gerätetypen, unterschiedlicher Hersteller und Kommunikationsprotokolle erlauben. Das FDT-System würde damit zum voll qualifizierten FDI Host.
FDI-Integration mit DTM-Installation vollzogen
Nun kann man sich sicherlich darüber freuen, wenn solch ein Adapter auf der Systemseite zur Verfügung steht, aber man könnte sich als Gerätehersteller eben nicht darauf verlassen, dass das auf allen Anlagen der Fall ist. Deshalb kann der Adapter auch direkt, mit integrierten FDI Device Packages des Geräteherstellers, ausgeliefert werden. Der Anwender würde auch in diesem Fall lediglich einen DTM installieren und würde noch nicht einmal bemerken, dass er seine Geräte eigentlich mit FDI Device Packages integriert hat.
Mit der Adapter-Strategie werden demnach die Anforderungen aller Beteiligten erfüllt: Die System-Lieferanten möchten den neuen, vereinheitlichten Standard sowohl ihren Neu- als auch ihren Bestandskunden auf einfache und risikolose Weise anbieten. Die Gerätehersteller möchten ab sofort die schwer kalkulierbaren Kosten (viele Host-Varianten müssen bedient werden, komplexe Softwareapplikationen, …) zur Erstellung und Pflege von Integrations- und Gerätemanagementprodukten reduzieren. Die Anwender profitieren sofort von der vereinheitlichten Lösung und sind zukunftssicher, ohne die bisherigen Investitionen über Bord werfen zu müssen. Innovation und Investitionsschutz sind damit auch hier überzeugend unter einen Hut gebracht.
Das ist durchaus kein Paradoxon und bei weitem keine Zukunftsmusik: CodeWrights nennt die Umsetzung dieser Adapter-Strategie iDTM (interpreter DTM). Viele Anwender nutzen bereits den EDDL-Adapter, den iDTM-EDD. Der iDTM-FDI (Tech Preview kostenfrei downloadbar) ist das neue Mitglied der iDTM-Familie und dabei Geräte-DTM und FDI Host in einem. Er ist der FDI-Adapter für alle FDT-Rahmenapplikationen.
