Für die Verwendung einer Container-Komponente lassen sich zwei Szenarien darstellen: Neuentwicklung einer Frame-Applikation oder Integration in eine bestehende Lösung.
Die Neuentwicklung kann auf der Basis der Add-Ons erfolgen. Diese lassen sich, wie bereits beschrieben, individuell ergänzen, erweitern oder ersetzen. Ein einfacher FDT-Frame kann bereits mit dem mitgelieferten Beispiel-Code der Container-Komponente in Betrieb genommen werden. Geht es hingegen um die Integration in eine bestehende Applikation, so existieren in der Regel bereits die wesentlichen Teile der Benutzerschnittstelle. Die lose Kopplung aller Komponenten ermöglicht das Ersetzen einzelner externer Komponenten, ohne hierzu die FDT-Container-Komponente oder weitere externe Komponenten bearbeiten zu müssen. Je nach Anwendungsfall kann dies sogar zur Laufzeit geschehen. Um eine Komponente zu ersetzen, muss die neue Komponente lediglich die notwendigen einfachen Schnittstellen implementieren. Es ist nicht zwingend erforderlich, dass spezielle FDT/DTM-Interfaces implementiert oder verwendet werden. Auf diese Weise lässt sich beispielsweise einfach das bewährte Look & Feel der Applikation beibehalten.
Wie hoch der Aufwand einer Integration letztendlich ist, hängt stark von den Strukturen der bestehenden Software ab. Eine bestehende komponentenorientierte Architektur bietet die besten Voraussetzungen für eine erfolgreiche Integration. Die Integration in andere Architekturen ist jedoch nicht ausgeschlossen. Entscheidend ist in jedem Fall, dass die Investitionen in die bestehende Software gesichert sind. Grundsätzlich lässt sich der Integrationsaufwand in folgende Schritte unterteilen:
Erweiterung zum Communication- und Web-Server
Auf Grund der Flexibilität der FDT-Container-Komponente erschließen sich weitere Anwendungsmöglichkeiten. Zum Beispiel ist die Implementierung eines Windows-Services leicht möglich. Durch die Implementierung als Windows-Service kann die FDT-Container-Komponente ihren Service auch im Hintergrund erbringen. Der Plug&Play-Service von Windows ist beispielsweise ein Windows-Service. Dieser sorgt im Hintergrund für die Erkennung neuer Hardware und startet die notwendigen Aktionen. Unter bestimmten Voraussetzungen kann ein solcher Service unabhängig vom angemeldeten Benutzer seinen Dienst versehen. Dies ist etwa auf einem Server relevant, bei dem unter Umständen gar kein Benutzer angemeldet ist. Aufbauend auf einen Windows-Service ließe sich beispielsweise ein Communication-Server implementieren, der die Funktionalität einer FDT-Frame-Applikation im Intranet bereitstellt. Ein weiterer FDT-Frame könnte sich nun mit dem Communication-Server verbinden und Daten abrufen. Für den Anwender der Client-Applikation werden dadurch Feldgeräte erreichbar, die mit anderen Rechnern innerhalb des Netzwerkes verbunden sind. Da der Communication-Server seinerseits eine vollwertige FDT-Frame-Applikation sein kann, ergibt sich eine völlig neue Dimension der Dezentralisierung.
Komponenten einer FDT-Frame-Applikation |
|
FDT auf der Achema
Seit Ende letzten Jahres existiert die FDT Joint Interest Group (FDT JIG). Sie bildet eine Interessenvertretung der Unternehmen, die den FDT-Standard etablieren wollen, und koordiniert künftig die Aktivitäten rund um FDT. Mitglied sind dort derzeit Unternehmen wie ABB, Endress+Hauser, Invensys, Bartec, Siemens und Vega. Ihren ersten öffentlichen Auftritt hatte diese Gruppe auf der Hannover Messe und auch auf der Achema in Frankfurt wird sie mit einem eigene Stand vertreten sein (Halle 10.2, Stand J41).
Nähere Informationen:
fdtCONTAINER@mm-software.dewww.fdt-jig.com
Autor
Volker Herbst ist bei M&M Software in St. Georgen vorrangig im Bereich FDT tätig.
Günter Herkommer, Computer&AUTOMATION