Die FDT-Technologie spezifiziert Schnittstellen zwischen Softwarekomponenten mit dem Ziel, Funktionalitäten von Feldgeräten in SCADA- und Engineering-Tools integrieren zu können. Im Fokus steht insbesondere die Konfiguration und Diagnose dieser Geräte in ausgedehnten, heterogenen Netzwerken. Ein Knackpunkt bei der Verwendung von FDT im Rahmen der Fertigungsautomatisierung ist die Verschaltung von Eingangs- und Ausgangssignalen. Beim Einsatz von unterschiedlichen Feldbussen und Protokollen zeigt sich, dass an dieser Stelle die Spezifikation auch feldbus- und protokollspezifische Informationen enthält.

Sollen Prozessdaten mit Variablen im Engineering-System verschaltet werden, so stellt man fest, dass das entsprechende Objekt (FdtChannel) in der FDT-Spezifikation je nach eingesetztem Feldbus variiert. Dies hat zur Folge, dass jedes Engineering-Tool, welches Prozessdaten mit eigenen Objekten verknüpfen möchte, eine feldbusspezifische Implementierung vornehmen muss. Diese Anpassungen sind aufwendig und fehleranfällig. Des Weiteren reichen die angebotenen Informationen im Regelfall nicht aus, um eine Verknüpfung im Engineering- Tool durchzuführen. So benötigen beispielsweise Programmierwerkzeuge IEC-61131-konforme Datentypen beziehungsweise Variablennamen zur Verschaltung eines Signals.

Die FDT-Group, ein Zusammenschluss von Unternehmen, die es sich zur Aufgabe gemacht haben, einen internationalen Standard basierend auf der Field-Device- Tool-Technologie zu etablieren, hat diese Problematik erkannt und im August die technische Arbeitsgruppe „FDT Factory Automation“ ins Leben gerufen. Mit dem Ziel, FDT auch in der Fertigungsautomatisierung erfolgreich einzusetzen, besteht deren Aufgabe darin, spezifikationskonforme Lösungen zu erarbeiten, welche die Signalverschaltung ohne eine Änderung an der bestehenden Spezifikation zulassen und mit einem Annex oder „Best-Practice“-Dokument beschrieben werden können. Zwei Vorschläge sind diesbezüglich aktuell in der engeren Wahl:

1. Modellieren der Prozessdaten mittels des Interface IDtmSingelInstance- DataAccess:

Diese Schnittstelle wurde mit der FDTSpezifikation 1.2.1 eingeführt und ist gedacht für den Offline-Zugriff auf einzelne beziehungsweise auf Gruppen von Parametern im Device Type Manager (DTM), der „Treiber“-Komponente eines Feldgerätes. Ferner ist die Schnittstelle aufgrund ihrer Definition feldbus- und protokollunabhängig und könnte auch Gruppen von Prozessdaten modellieren. Die hier angestrebte Verwendung von IDtmSingel- InstanceDataAccess im Rahmen des Problems „Signalverschaltung“ entspricht jedoch nicht dem ursprünglichen Ziel dieser Schnittstelle. Der Grund: Eine Umsetzung der Anforderungen für die Signalverschaltung führt zu einer Vermischung zwischen Parameterdaten und Signaldaten. Laut FDT-Spezifikation ist aber das Interface IFdtChannel für die Darstellung von Signalinformationen zuständig. Für den Anwender würde es somit schwieriger, zu verstehen, warum die Signalinformationen über dieses Interface zur Verfügung gestellt werden.

Ferner bedingt der Einsatz von IDtm- SingleInstanceDataAccess die Implementierung eines DTM nach FDT-Spezifikation 1.2.1. Das bedeutet für den Gerätehersteller, dass er existierende, FDT-1.2-konforme DTMs nach FDT 1.2.1 überführen müsste. Neben dem Aufwand für die Umsetzung weiterer Interfaces nach FDT 1.2.1 bringt dies ein entsprechendes Fehlerrisiko mit sich. Nicht zu vergessen die Kosten für eine neue Zertifizierung des DTM.

Signalverschaltung zwischen dem IEC-61131-Programmiersystem Multiprog und dem KW-Software-FDT-Container. Die von Geräten aus dem FDT-Projekt zur Verfügung gestellten Signale (Prozesskanäle) werden mit Variablen aus dem Programmiersystem verknüpft.

2. Definition eines zusätzlichen, feldbusunabhängigen Busprotokolls, welches die busunabhängigen Informationen für die Signalverschaltung repräsentiert:

Diese Informationen sind neben den feldbusspezifischen Daten ebenfalls am IFdt- Channel über die zugehörige Protokoll-ID abrufbar. Der Vorteil dieser Lösung besteht darin, dass sie genau an dem Interface implementiert würde, an dem auch die FDTSpezifikation die Informationen zu einem Prozessdatum ablegt. DTMs nach FDT 1.2 können ebenfalls von dieser Erweiterung Gebrauch machen. Bei dieser Umsetzung müssen lediglich ein neues allgemeines Schema und eine „Protokoll-ID“ der FDTSpezifikation in Form eines Annex hinzugefügt und keine weiteren Interfaces in der FDT-Spezifikation definiert werden. Nach der Implementierung des Busprotokolls „Signalverschaltung“ durch DTM und FDT-Container lassen sich sowohl DTM nach FDT 1.2 sowie 1.2.1 mittels FDTMechanismen für die Signalverschaltung heranziehen.

Sollte sich die Arbeitsgruppe mit dem FDT-Core-Team für die zweite Lösung entscheiden, so kann zeitnah die Definition einer entsprechenden Schema- Datei erfolgen und im Jahr 2009 bereits eine praktikable Lösung für das Signalhandling vorliegen. Soviel zum Thema Signalverarbeitung. Heutige Anlagen in der Fertigungstechnik bestehen oftmals aus mehreren Steuerungen und Feldbussen und einer Vielzahl von Geräten. Typischerweise sind diese Anlagen in Zellen unterteilt, die identisch aufgebaut sind. Innerhalb dieser Zellen finden ebenfalls bevorzugt gleichartige Geräte Verwendung, um den Wartungsaufwand zu reduzieren. Diese Geräte bedürfen meist einer ähnlichen Parametrierung. FDT bietet hierfür entsprechende Interfaces auf Geräte-Ebene an.

Parametrierung gleichartiger Geräte

Die FDT-Spezifikation 1.2 definiert das Interface IDtm- OnlineParameter als optionales Interface, welches den lesenden und schreibenden Zugriff auf Geräteparameter zulässt. Ergänzend bietet FDT 1.2.1 das Interface IDtmSingleDeviceDataAccess an, welches die Schwäche des Interface IDtmOnlineParameter behebt, nur alle Parameter gleichzeitig schreiben zu können. Aber auch die Umsetzung aus der FDT-Spezifikation 1.2.1 bei der Verwendung einer Vielzahl gleichartiger Geräte ist „zu kurz geschossen“. Denn sie bietet keinen Lösungsansatz, wie der Anwender mehrere Geräte gleichzeitig mit demselben oder einem ähnlichen Parametersatz konfigurieren kann.

Dieser Problematik muss sich die Arbeitsgruppe FDTFA stellen, nachdem die Arbeiten an der Signalverschaltung abgeschlossen sind. Wenn FDT sich in der Fertigungsautomatisierung durchsetzen soll, so kann der Anwender nicht genötigt werden, die identische Parametrierung dutzender Geräte vornehmen zu müssen, und im Anschluss den Parametersatz noch manuell in jedes einzelne Gerät zu übermitteln. Die Software FDT-Container von KW bietet hier bereits eine Lösung, indem sie es dem Anwender ermöglicht, die Parametrierung ganzer Netzwerk-Ebenen mit einem Mausklick durchzuführen.

Die Integrations-Thematik

Seit der Freigabe der FDT-Spezifikation 1.2 im Jahr 2001 und der Version 1.2.1 im Jahr 2005 haben die Gerätehersteller viele DTM entwickelt. Allerdings setzen nicht alle Engineering-Systeme diese Schnittstelle um, so dass viele DTM der Gerätehersteller in diesen Engineering- Systemen gar nicht zum Tragen kommen. Dem Endanwender geht an dieser Stelle eine Menge Know-how und Komfortabilität bei der Konfiguration seiner Feldgeräte verloren. Soll in einem Engineering-System, welches FDT nicht unterstützt, bis auf Sensor/Aktor-Ebene parametriert werden, so muss die Gerätesoftware ein weiteres proprietäres Interface unterstützen, damit sie vom Engineering- System verwendbar ist. Das bedeutet wiederum erhöhten Aufwand für die Entwicklung und Pflege der Gerätesoftware. Um die Vielzahl der bereits existierenden DTMs auch in Systemen nutzen zu können, die nicht auf FDT setzen, bietet beispielsweise der FDT-Container von KW-Software zwei mögliche Migrationswege:

Die auf dem Automation-Framework von KW-Software basierende Komponentenstruktur des FDT-Containers ermöglicht die nahtlose Integration in beliebige Applikationen.

1. Die zusätzliche Schnittstelle TCI (Tool Calling Interface, Conformance Class 3):

Mittels TCI lassen sich Informationen vom Engineering-System an den FDT-Container bis zum DTM weitergeben. Das Tool Calling Interface wurde von der Profibus-Nutzerorganisation für Profibus und Profinet definiert. Einzige Einschränkung dieser Schnittstelle ist, dass der Datenfluss nur vom Engineering-Tool zur Gerätesoftware erfolgt, nicht aber zurück. Änderungen der Gerätekonfiguration im DTM des FDT-Containers müssen manuell in das Engineering-Tool übernommen werden. Bei der Kommunikation mit dem Gerät ist der TCI-Communication- Server verwendbar, so dass die Kommunikationsparameter nicht nochmal vom Anwender einzustellen sind. Es lassen sich aber auch beliebige Kommunikations- DTM für Profibus beziehungsweise Profinet nutzen.

2. Integration der FDT-Komponenten in das Engineering-System:

Ist die Rückübermittlung der Daten aus dem FDT-Container in das Engineering- Tool wichtig, so besteht bei den FDTKomponenten die Möglichkeit der tiefen Integration in ein Engineering-System auf Basis des Automation-Framework von KW Software. Über das Component- und Standard-UI-Framework lassen sich beliebige Drittkomponenten hinzufügen. Aber auch eine Integration ohne Automation- Framework-Komponenten ist möglich. Zusammenfassend lässt sich sagen: Tools für die Signalverschaltung mittels FDT-Technologie zu erstellen, ist zwar heute noch sehr aufwendig, aber machbar. Ist es geschafft, bieten diese Tools den Vorteil, I/O-Punkte hersteller- und netzwerkübergreifend verknüpfen zu können. Mit dem Ergebnis aus der FDT-Arbeitsgruppe „Factory Automation“ für das Problem der Signalverschaltung und den am Markt existierenden Lösungen für die Integration der FDT-Technologie in Engineering-Systeme sind die Aussichten für FDT im Bereich der Fertigungsautomatisierung mindestens ebenso erfolgversprechend wie im Bereich Prozesstechnik.

Autor: Olaf Zarges ist Leitender Ingenieur im Geschäftsfeld Control bei KW-Software, Lemgo.