Herr Brill was verursachte die Verzögerungen beim Freigabeprozess?

Die Verzögerungen wurden durch drei Gründe verursacht. Erstens waren die Abstimmungen mit dem FDI-Konsortium sehr zeitaufwendig, da deren Spezifikationen noch nicht soweit gediehen waren. Zweitens haben wir parallel zur Spezifikation das Entwicklungsprojekt „Common-Components“ gestartet. Deren parallele Implementierung hatte Rückwirkungen auf die FDT-Spezifikation. Und drittens wurden kurzfristig mit der physikalischen Topologie, den statischen Funktionen und dem DTM-Nachrichtenaustausch zusätzliche Funktionen in die Spezifikation aufgenommen. Besonders die beiden letzten Punkte waren uns so wichtig, dass wir dafür eine spätere Freigabe der Spezifikation in Kauf genommen haben.

Ein wichtiger Aspekt bei Technologiewechsel ist stets die Rückwärtskompatibilität.

Auf die Rückwärtskompatibilität haben wir bei der Definition von FDT2 großen Wert gelegt. Für die Akzpetanz und schnelle Umsetzung ist es unabdingbar, dass sich auch existierende DTMs in FDT2-basierte Rahmenapplikationen weiterverwenden lassen. Hierzu gibt es entsprechende Mechanismen.

Parallel zur neuen Spezifikation wurde eine Entwicklungssoftware vorgestellt – FDT-Express.

Mit FDT-Express ist es möglich, die FDT-Schnittstellen direkt in der Entwicklungsumgebung Visual Studio zu nutzen. Entwickler können darüber FDT einfacher und schneller in ihre Programme implementieren.

Welche Zielsetzung verfolgt die FDT-Group mit der Festlegung auf die Common-Components und die von der Firma M&M-Software implementierte Lösung?

Common-Components stellen den Herstellern von Geräte- oder Rahmenapplikationen Basiskomponenten zur Verfügung, welche die FDT-Funktionalität kapseln. Diese Komponenten wurden intensiv getestet, so dass die Interoperabilität von FDT2-Implementierungen von Anfang an sichergestellt ist. Insgesamt erzielen wir damit einen wesentlich stabilere und schnellere Markteinführung.

Und welche Rolle hat dabei die Firma M&M-Software?

Bei den Common-Components muss man zwischen DTM und Rahmenapplikation unterscheiden. Für DTMs hat die FDT-Group ein eigenes Entwicklungsprojekt aufgesetzt, für Rahmenapplikationen hatte M&M-Software bereits eine Lösung entwickelt, die viele FDT-Mitglieder nutzen. Eine eigenständige Neuentwicklung wie für DTMs wäre wirtschaftlich nicht sinnvoll gewesen. Daher haben wir die Rahmenapplikation von M&M als Common-Component zertifiziert.

Indirekt schreibt die FDT-Group damit die Nutzung der M&M-Software vor. Wie vermeiden Sie Konflikte beispielsweise hinsichtlich Lizenzgebühren oder künftiger Software-Updates?

Die FDT-Group empfiehlt nur die Nutzung des M&M-Tools, da es die Entwicklungskosten für Rahmenapplikationen reduziert – trotz der Lizenzgebühren. Wir haben ein Abkommen mit M&M geschlossen, das uns Mitspracherechte bei der Weiterentwicklung einräumt. Für den Fall, dass M&M, aus welchen Gründen auch immer, die Entwicklung einstellt, gehen die Rechte inklusive Sourcecode an die FDT-Group über. Damit ist sichergestellt, dass unsere Mitglieder keinerlei Nachteile durch die Nutzung der M&M-Rahmenapplikation zu befürchten haben.

Die FDT-Group engagiert sich auch in der FDI-Cooperation. Wie sieht die Integration von FDI in FDT 2 aus?

Für die Integration von FDI-Packages wird es einen FDI-Interpreter als DTM geben. Dies funktioniert ähnlich wie bei den existierenden EDDL-Interpreter-DTMs. Für uns ist FDI ein Subset von FDT, zumal FDI nur die drei Feldbus-Systeme aus der Prozessautomation unterstützt. Die FDT-Group verfolgt hier einen wesentlich breiteren Ansatz.

Warum funktioniert die Integration nicht auch in umgekehrter Richtung, von FDT zu FDI?

Eine Integration von DTMs ist beim FDI-Konzept nicht vorgesehen. Man hat sich bei der Business-Logic der Geräte auf die EDDL beschränkt, was bei komplexen Geräten zu Problemen führen kann.