Der Migrationspfad von FDT zu FDI

Die Entwicklung von FDT begann in den frühen 2000er Jahren, um die Integration und Interoperabilität von Feldgeräten in Automatisierungssystemen zu verbessern. Initiiert von führenden Automatisierungsunternehmen, bot FDT eine herstellerunabhängige Plattform für die Kommunikation und Verwaltung von Geräten. FDI entstand später als Antwort auf die wachsenden Anforderungen an eine vereinfachte und konsistente Benutzererfahrung. FDI kombiniert die Vorteile von FDT und EDDL (Electronic Device Description Language), um eine umfassendere Lösung zu bieten, die die Integration und Verwaltung von Feldgeräten weiter vereinfacht.

Da die FieldComm Group, Eigentümerin der FDI-basierten Technologie, nun auch die FDT-Technologie besitzt, müssen Gerätehersteller, deren Produkte auf der FDT-Technologie basieren, mehrere Dinge berücksichtigen.

Die FDT-Historie

Der Großteil der bestehenden FDT-basierten Produkte am Markt basiert auf der FDT-Version 1.2. Sie ist streng an Windows gebunden und inzwischen um die 20 Jahre alt. Die späteren Spezifikationen 2.0 und 3.0 sollten die zugrundeliegende Technologie an aktuelle Standards wie WebUIs und plattformunabhängige Komponententechnik anpassen. Allerdings werden FDT 2 und FDT 3 in marktreifen Produkten von Geräte- und Host-Herstellern weitaus seltener eingesetzt. ach der Übertragung der FDT-Technologie durch die FieldCom-Group wurde bekannt gegeben, dass FDT 1.2 und FDT 2.0 in einen reinen Wartungszustand versetzt werden. Auch künftige Spezifikationsarbeiten an Kernspezifikationen von FDT 3.0 sowie die Entwicklung von Werkzeugen werden sich auf notwendige Wartungsarbeiten beschränken. Neue Spezifikationen und neue Funktionen für bestehende Spezifikationen, die über die bereits in Arbeit befindlichen hinausgehen, werden künftig nicht mehr erstellt. Ein Beispiel für bereits in Arbeit befindliche Spezifikationen sind die FDT 3-Protokollanhänge für IO-Link und Foundation Fieldbus. Das zukünftige Ziel ist es, eine FDI-Spezifikation zu erstellen, die die bestehenden FDT- und FDI-Welten miteinander 'verheiratet'.

Da ein Großteil der am Markt verfügbaren FDT-Komponenten zudem auf dem von Microsoft bereits abgekündigten .Net Framework beruhen, besteht auch deshalb dringender Handlungsbedarf für die Gerätehersteller – insbesondere unter dem Aspekt der Anforderungen des Cyber Resilience Acts.

Von FDT-DTM zu FDI-DevicePackage

In FDT erstellt der Gerätehersteller eine binäre Komponente, für spezifizierte Schnittstellen wird die Gerätelogik in C# oder C++ ausprogrammiert. Dieses DTM wird auf dem Zielrechner mit einem eigenen Setup für Windows installiert. Ein FDT-Server sucht anschließend nach den installierten DTMs. © FieldCom Group

Es wird schwierig sein, vorhandene FDT-Softwarekomponenten, sogenannte DTMs (Device Type Manager), in FDI wiederzuverwenden. In FDT werden die Gerätelogik und das Userinterface typischerweise in einer Programmiersprache wie C++ oder C# auf Basis des abgekündigten .Net Frameworks von Microsoft erstellt, für eine bestimmte Plattform übersetzt und als Binärkomponente für Windows (oft eine bestimmte Version von Windows) ausgeliefert und installiert. FDT 2 und FDT 3 bieten zusätzlich die Möglichkeit, Userinterfaces mit Webtechnologien (als HTML und JavaScript) zu erstellen. Allerdings basieren die meisten auf dem Markt erhältlichen Produkte auf der FDT 1.2-Technologie.

In FDI werden die Gerätelogik und das UI mittels einer EDDL beschrieben und in ein Plattform unabhängiges Binärformat konvertiert. Dies wird zusammen mit zum Beispiel technischer Dokumentation in ein FDI Device Package (ähnlich wie eine ZIP-Datei) verpackt. Ein FDI-Server importiert ein solches Package, interpretiert das Binärformat und führt dieses dann aus.

Neben der Möglichkeit, das Userinterface in EDDL zu beschreiben, bietet FDI die Möglichkeit, Userinterfaces mittels HTML und Javascript zu erstellen und diese als UIPs (User Interface Plugin) in einem Device Package mit bereitzustellen. Bestehende, ausprogrammierte FDT-DTM Userinterfaces müssen mit Webtechnologien neu erstellt werden. 

Aus diesem Grund sollten Gerätehersteller neue Investitionen in FDT-Technologie, insbesondere in FDT 1.2-Technologie, sorgfältig abwägen. Hersteller von Feldgeräten sollten so bald wie möglich mit der Entwicklung von FDI Device Packages beginnen.

Kommunikation in geschachtelten Topologien

In FDI erstellt der Gerätehersteller ein Package (als signierte ZIP-Datei mit definierter Struktur und Metadaten). Die Gerätelogik und das UI werden in Form einer EDD beschrieben. Ein FDI-Server lädt dieses Package und interpretiert diese EDD zur Kommunikation mit dem Device und zur Darstellung des UI. Neben der Möglichkeit, mit Clients auf unterschiedlichen Plattformen mit den Geräten mittels der Packages zu arbeiten, definiert FDI auch ein OPC UA-Modell zur Integration aller Geräteinformationen einer Anlage in IoT Szenarien. © FieldCom Group

Hersteller von Kommunikationskomponenten, zum Beispiel Remote-IOs, haben das Problem, dass aktuell in FDI eine Realisierung eines Device Packages für sogenannte Gateways, also Protokollumsetzer zwischen unterschiedlicher Feldbustechnologien, unter Verwendung einer EDDL nicht möglich ist. Aspekte wie Parallelität von mehreren Requests, Timeouts, Queues sowie komplexe Byte-Operationen scheinen mit einer EDDL nicht realisierbar. Es sind unseres Wissens auch keine solch artigen FDI Packages für Gateways am Markt verfügbar.

FDI benötigt hierfür eine Lösung in Form von binären, aber plattformunabhängigen Plug-ins, die als zusätzliches Element in einem entsprechenden Gerätepaket eines Gateways enthalten sein werden. Solche Plug-ins werden in C# für das aktuelle und plattformunabhängige Microsoft .Net programmiert. Diese Spezifikationsarbeit steht kurz vor dem Abschluss.

ABB Field Information Manager auf Basis von FDI

ABB zeigt mit dem Field Information Manager, wie auch für tief verschachtelte Feldbustopologien mit mehreren zehntausenden Feldgeräten und unterschiedlichsten Feldbus-Technologien (wie HART, Profibus, Profinet, Ethernet-APL, Hart IP, Ethernet-IP, ASi) in einer großen Anlage ein rein auf FDI basierendes Gerätemanagement möglich ist. Dort können bereits seit ein paar Jahren erweiterte, ABB spezifische Device Packages (sogenannte FIMlets) verwendet werden, die eine binäre, aber Plattform unabhängige, in C# für Microsoft .Net erstellte Komponente zur Realisierung der Protokoll-Umsetzung mit standardisierten Schnittstellen beinhalten. ABB bietet den Geräteherstellern dazu ein Software Development Kit (SDK), das die Erstellung eines solchen FIMlets mit überschaubarem Aufwand ermöglicht.

Mit dem Wissen über die in einem existierenden FDT-DTM ausprogrammierte Gerätefunktionalität lässt sich ein entsprechendes FDI Device Package als EDDL erstellen. Bereits heute ist es mit PACTware in einem einzigen Tool möglich, dasselbe Feldgerät entweder mit dem entsprechenden FDT-DTM oder einem neu erstellten FDI-Package zu konfigurieren und damit die Qualität der Migration von FDT zu FDI zu überprüfen.

Migrationspfad für Gerätehersteller

Gerätehersteller, deren Produkte heute auf Basis von FDT/DTM in Systeme integriert werden, sollten die Migration zu FDI-Packages unmittelbar angehen. Seitens der FieldComm-Group stehen die Entwicklungswerkzeuge zur Verfügung. Zudem steht mit PACTware ein kostenfreies Werkzeug zur Verfügung, um beide Welten, FDI und FDT, gemeinsam in einer Anlage zu betreiben. Durch die Erstellung eines ABB FIMlet können Hersteller von Remote-IOs, also Protokollkonvertern, sich bestmöglich auf das bevorstehende Update der FDI 1.5-Spezifikation vorbereiten, das erst in einigen Monaten verfügbar sein wird.