Beispiel für ein einfaches Gerätenetz sowie die korrespondierende Topologie innerhalb der FDTRahmenapplikation im FDT-Container: Der Benutzer greift mittels der grafischen Benutzerschnittstelle (1) des Geräte-DTM (2) auf die Daten des Feldgerätes (5) zu. Um die Kommunikation mit dem Gerät zu ermöglichen, werden die entsprechenden Kommunikations- (3) und Gateway- DTM (4) genutzt.

© Siemens, M&M Software

Das Gesamtsystem besteht aus der FDT-Rahmenanwendung mit einem Plug- In zur Konfiguration des OPC-Servers sowie dem OPC-Server für die Anbindung von OPC-Clients. FDT dient dabei als „unterlagerte" Technologie zur Kommunikation mit den Feldgeräten und der Datenerfassung. Die gesammelten Daten werden über den OPC-Server bereitgestellt und sind somit für beliebige OPCClients zugreifbar.

Im Detail läuft dieser Prozess mehrstufig ab: Zunächst wird das Projekt innerhalb der FDT-Rahmenanwendung erstellt. Konkret bedeutet dies, dass für sämtliche Hardwarekomponenten innerhalb der Anlage (Kommunikationshardware, Gateways, Sensoren und Aktoren) entsprechende DTM in die Netzwerktopologie integriert werden. Die so erstellte Topologie spiegelt den realen Aufbau des Gerätenetzes wieder.

Nun ist zwar der Datenzugriff durch einen Benutzer möglich; eine Applikation für den automatisierten Datenzugriff - zum Beispiel zum Zweck des Condition Monitoring - lässt sich jedoch nicht anbinden. Um dies zu realisieren, wird auf der Basis der Netzwerktopologie automatisch ein OPC-Namensraum (OPC namespace) generiert. Dieser Namensraum ist eine logische Datengruppierung, in der alle Geräte und deren Parameter eindeutige Namen zugewiesen bekommen. Die Hierarchie korrespondiert mit der Netzwerktopologie. Das untere Bild verdeutlicht den Aufbau des Namensraumes: Unterhalb jedes Geräteknotens (Device 1, 2, 3) werden die zur Verfügung stehenden Parameter in Form von OPC-Items (Verbindung zu einer Prozessvariablen; IO 1, Alarm 1...) repräsentiert.

Die Generierung des OPCNamenraums erfolgt automatisch aus den DTM-Informationen.

© Siemens, M&M Software

Die zur Erzeugung der OPC-Items notwendigen Informationen werden über die FDT-Schnittstellen „IFdtChannelParameter" oder „IDtm SingleDeviceDataAccess" direkt vom DTM abgefragt. Der Zugriff auf I/O-Signale, Prozesswerte und Geräteparameter ist somit sowohl über Process Channels als auch über Single Device Data Access möglich. Beim Hinzufügen oder Entfernen eines DTM zur Topologie bleibt der Namensraum stets konsistent, das heißt, entsprechende Änderungen werden direkt übernommen. Ebenfalls kann der Benutzer den automatisch erzeugten Namensraum anpassen, also beispielsweise bestimmte Geräte oder OPC-Items ausblenden.

Sollte der Geräte-DTM nicht alle notwendigen Informationen über Process Channels oder Single Device Data Access zur Verfügung stellen, so besteht die Möglichkeit, zusätzliche Informationen manuell hinzuzufügen. Hierfür wird eine XMLDatei importiert, in der die zugreifbaren Geräte-Informationen beschrieben sind. Im Fall von Profibus kann dies beispielsweise ein über einen definierten Slot und Index zugreifbarer Parameter inklusive des Datentyps sein.

OPC-Server arbeitet im Hintergrund

Alle bislang aufgezeigten Aktionen zur Generierung und Anpassung des OPCNamensraumes erfolgen - ebenso wie die weitergehende Konfiguration des OPCServers (Zugriffintervalle, Logging, Zugriffsrechte usw.) - innerhalb der FDTRahmenapplikation. Diese übergibt nun sämtliche Informationen mittels einer spezifischen Schnittstelle an einen speziellen OPC-Server. Dieser OPC-Server hat keine eigene grafische Benutzerschnittstelle, sondern arbeitet als Windows- Service im Hintergrund. Er implementiert einen eigenen FDT-Container und kann somit eigenständig DTM ausführen. Die FDT-Rahmenapplikation, in der die Durchführung des eigentlichen Engineering erfolgt, ist daher für den weiteren Betrieb nicht mehr notwendig. Bei Bedarf ist sie aber weiterhin für die (Re-) Konfiguration des OPC-Servers nutzbar.

Abhängig von der genutzten Kommunikationsmethode lädt der OPC-Server alle oder nur die zur Kommunikation mit dem Gerät notwendigen DTM. Als Kommunikationsmethoden stehen sowohl Process Channels wie auch Single Device Data Access zur Verfügung. Der Server entscheidet selbstständig, welche Methode er nutzt. Bevorzugt findet der direkte Zugriff auf die Parameter im Gerät über Process Channels statt. In diesem Fall sind nur die Kommunikations- und Gateway- DTM zu laden, nicht jedoch die Geräte- DTM. Dies spart erheblich Ressourcen, da sich die Anzahl der gestarteten DTM auf ein Minimum reduziert, und beschleunigt die Datenübertragung. Allerdings ist dieses Verfahren protokollspezifisch, weil der OPC-Server protokollabhängige Kommunikationstelegramme (etwa Profibus-Read-Requests) zum Lesen der Daten erstellen muss.

Beispielsweise unterstützt der OPCServer zur FDT-Container-Applikation von M&M Software dieses Verfahren für HART, Profibus und Foundation Fieldbus. Stellt der DTM die gewünschten Daten nicht über Process Channels zur Verfügung, oder kommt ein unbekanntes Protokoll zum Einsatz, so erfolgt der Datenzugriff über Single Device Data Access. Im Gegensatz zum Zugriff über Process Channels findet die Kommunikation hier nicht direkt mit dem Gerät statt, sondern über die Schnittstelle „IDtmSingleDeviceDataAccess" des Geräte-DTM. Dabei müssen folglich neben den Kommunikations- und Gateway-DTM die entsprechenden Geräte-DTM geladen werden. Das bedeutet eine höhere Ressourcenbelastung und langsamere Kommunikation, hat jedoch den Vorteil der Protokoll-Unabhängigkeit.

Die genutzte Kommunikationsmethode - Process Channels oder Single Device Data Access - ist für einen OPCClient transparent, da der Datenzugriff über Standard- OPC-Schnittstellen erfolgt. Der OPC-Server selbst implementiert keinerlei CM-Funktionalitäten; seine Aufgabe beschränkt sich auf die Kommunikation mit den Feldgeräten und das Bereitstellen der gesammelten Daten. Auf diese Daten kann eine beliebige Applikation mittels OPCSchnittstellen zugreifen. Dabei kann es sich um ein Condition- Monitoring- oder ein Asset-Management-System handeln, aber auch um eine Prozessvisualisierung wie etwa WinCC von Siemens.

Das vorgestellte Konzept stellt dem Anwender eine ganzheitliche Lösung für die Konfiguration des Netzwerks, die Geräteparametrierung sowie die Datenanbindung bereit. Dies führt, sowohl während des Engineering-Prozesses, als auch in der späteren Betriebsphase zur spürbaren Zeit- und Kosteneinsparungen. Die Lösung ist unabhängig von den eingesetzten Geräten, der Netzwerkstruktur und den verwendeten Kommunikationsprotokollen. Dem Anwender ermöglicht dies den Einsatz des jeweils optimalen Gerätes für die spezifischen Aufgaben, ohne dass Kompromisse hinsichtlich Bedienkomfort oder nutzbarem Funktionsumfang eingegangen werden müssen.

Autoren:
Christian Gnädig ist Sales Manager bei der Firma M&M Software, St. Georgen.

Volker Herbst ist Sales Manager bei der Firma M&M Software, St. Georgen.

FDT - die Technologie

Das Field-Device-Tool-Konzept - kurz FDT - definiert eine Schnittstelle, welche die Integration von intelligenten Feldgeräten, Antrieben oder auch von IO-Baugruppen in verschiedene Systeme ermöglicht. Für den spezifischen Zugriff auf die Feldgeräte sorgen die Device Type Manager (DTM), die in ihrer prinzipiellen Funktion mit Gerätetreibern (zum Beispiel Druckertreibern) vergleichbar sind. Somit wird die Grundlage für ein „Plug&Play" von Feldgeräten geschaffen. Ein DTM ist ein Software- Modul, das in der Regel zusammen mit dem Gerät ausgeliefert wird und alle gerätespezifischen Daten und Parametrierregeln kapselt. Pro Gerätetyp oder Gerätefamilie ist ein DTM erforderlich.