Methoden des Feldbuszugriffs bei PCs unter MS-Windows - ein State-of-the-Art-Report Prof. Dr.-Ing. Jörg Böttcher, Deggendorf Zusammenfassung Der vorliegende Beitrag gibt einen Überblick über die heute verbreiteten Verfahren zur Ankopplung von Feldbussen an Anwendungsprogramme, die unter MS-Windows auf PCs ablaufen. Nach einer einleitenden Betrachtung der von Seiten der Koppelhardware (Einsteckkarte, serielle/parallele Schnittstelle, PCMCIA-Karte) vorgegebenen Bedingungen werden die folgenden vier Methoden näher untersucht: Programm-implizites Verfahren, Aufruf über DLL, Aufruf über DDE, Aufruf über OLE. Unter OLE wird insbesondere das sich zur Zeit als zukünftiger Standard etablierende OLE 2 Automation intesiver erläutert. Abschließende Bemerkungen über die Verfügbarkeit von Produkten zu den einzelnen Verfahren beschließen die Ausführungen. 1. Bedingungen der Koppelhardware Prinzipiell lassen sich die in Bild 1 dargestellten Varianten der Buskoppelhardware unterscheiden. Bild 1: Varianten der Buskoppelhardware Während die Hardwarevariante keinen größeren Einfluß auf die Gestaltung von Feldbustreibern unter Windows besitzt, weisen unterschiedliche Feldbusse durchaus unterschiedliche Philosophien in Bezug auf den Anwenderzugriff auf (Bild 2). Bei den Diensteorientierten Zugriffsarten typischer Universalbussysteme - zum Beispiel der in der europäischen Feldbusnorm EN 50170 enthaltenen P-NET, PROFIBUS und WorldFIP - hängt die Komplexität der Treibersoftware wesentlich von der Anzahl und der Struktur der verwendeten Dienste ab. Hardware-nahe Zugriffsverfahren - wie bei CAN - verlagern zwar einen größeren Teil des eigentlichen Busprotokolls in die Hardware, dafür müssen aber teilweise
umfangreichere Übergabe- und Synchronisationsmechanismen zwischen Treiber und Peripheriechips der Hardware durchgeführt werden. Programm-implizite Zugriffsverfahren (z.b. LON) erfordern in der Regel zwischen Applikationsprogramm und eigentlichem Feldbus- Treiber noch ein programmspezifisches Betriebssystem, das automatisch vom Entwicklungssystem dazugelinkt wird. Bild 2: Der Anwenderzugriff Im folgenden wird im wesentlichen von einer für den Dienste-orientierten Zugriff geeigneten Struktur der Software unter Windows ausgegangen. Für die anderen Zugriffsarten sind leicht abgewandelte Strukturen geläufig, die jedoch von denselben Grundvarianten ausgehen. 2. Programm-implizites Verfahren Bild 3 gibt im Überblick die wesentlichen Eigenschaften des Programm-impliziten Zugriffs wieder. Bild 3: Programm-implizites Verfahren Dieses heute nur in wenigen Fällen angewandte Verfahren erfordert sehr detaillierte Kennt-
nisse der verwendeten Hardware sowie einer Programmiersprache mit ihren syntaktischen und semantischen Definitionen für Ein- und Ausgaben von/zu der Peripherie. Diese Verfahren sind oftmals in leicht abgewandelter Form aus früheren Anwendungen unter DOS entnommen und unterstützen nicht die heute unter Windows mögliche offene Systemgestaltung. 3. Aufruf über DLL DLL bedeutet Dynamic Link Library. Darunter sind sogenannte dynamische Bibliotheken zu verstehen, die Funktionen enthalten, die von Windows-Programmen aufgerufen werden können. Im Unterschied zu klassischen DOS-Bibliotheken werden DLLs beim Systemstart fest in den Arbeitsspeicher geladen. Ihre Funktionen können von allen aktiven Windows- Applikationen quasi-parallel aufgerufen werden. Windows selbst besteht letztlich auch vor allem aus zahlreichen DLLs, die in ihrer Gesamtheit das sogenannte API (Application Program Interface) bilden. Feldbus-Treiber in Form von DLLs ergänzen somit das Windowseigene API um eine Feldbus-API. Bild 4 gibt die wesentlichen Charakteristika wieder. Bild 4: Aufruf über DLL DLLs sind die heute unter Windows am verbreitetsten Treibervarianten. Sie werden für alle gängigen Feldbushardware-Varianten angeboten. Da es sich um Funktionsaufrufe im klassischen Sinn handelt, müssen allerdings die Anwendungsprogramme ebenfalls spezielle Programmkonstrukte zum Ansprechen der DLL-Funktionen enthalten. Die heute in der Automatisierungstechnik weit verbreiteten Standard-Software-Pakete für Visualisier- bzw. SCADA-Anwendungen unterstützen über entsprechende DLLs zwar teilweise eine beträchtliche Vielzahl von Meßdatenerfassungskarten, verfügen aber in der Regel über keine DLLs für spezielle Feldbusanschaltungen. Spezielle Feldbus-DLLs können jedoch teilweise dadurch angesprochen werden, daß die Standardpakete um entsprechenden Programmcode (z.b. in Visual Basic oder C) vom Anwender erweitert werden, was allerdings nicht bei allen Produkten möglich ist. 4. Aufruf über DDE DDE-Verknüpfungen (Dynamic Data Exchange) zwischen Windows-Applikationen wurden
von Microsoft bereits bei früheren Versionen von Windows eingeführt, um Daten online zwischen verschiedenen Anwendungen auszutauschen. Speziell im Feldbusbereich bieten einige Hersteller DDE-Treiber (sog. Server) an. Die wichtigsten Eigenschaften führt Bild 5 an. Bild 5: Aufruf über DDE Bild 6: DDE-Feldbus-Zugriff am Beispiel EN 50170 (Vol. 1 P-NET) Das Anwenderprogramm muß zunächst eine DDE-Verbindung zum DDE-Treiber herstellen, indem es den Treibernamen (Service) und einen Treiberunterabschnitt (Topic) innerhalb eines DDE-Initialisierungsbefehls spezifiziert. Bei den meisten DDE-Feldbustreibern kann nur ein Unterabschnitt angegeben werden. Anschließend kann man beispielsweise über entsprechende DDE-Lese- oder Schreibzugriffe einzelne Prozeßwerte ansprechen, wobei diese stets über symbolische Namen (Item) adressiert werden. Wie das Beispiel in Bild 6 zeigt, existieren in der Regel entsprechende Initialisierungsdateien, welche die Zuordnungen zwischen symbolischen Namen und Bus-Adressen der Prozeßwerte enthalten. DDE wird heute von allen Standard-Paketen unterstützt. Der Anwender muß meist zuerst den DDE-Treiber aufrufen, die entsprechenden Initialisierungsmaßnahmen vornehmen und kann dann rein mit den symbolischen Namen im Anwendungsprogramm arbeiten.
5. Aufruf über OLE OLE (Object Linking and Embedding) ist ebenfalls eine von Microsoft fest in Windows implementierte Methode des Austausches von Informationen zwischen Programmen. Im Gegensatz zu DDE, das vor allem für den Austausch kleinerer Datenmengen entwickelt wurde, arbeitet OLE auf Objektbasis. Objekte können beispielsweise komplette Programme, Programmteile, Tabellen, Grafiken oder auch nur einzelne Werte sein. Das speziell seit der Windows-Version 3.11 integrierte OLE 2 Automation erlaubt entsprechend programmierten Applikationen, sogenannte OLE-Automatisierungsobjekte (auch exponierte Objekte genannt) anderen Applikationen zur Verfügung zu stellen. Dies bedeutet, daß die anderen Applikationen sowohl auf die Eigenschaften (properties) als auch Methoden (methods) dieser Objekte zugreifen können. Bild 7 gibt einige grundlegende Eigenschaften von OLE wieder. Bild 8: Aufruf über OLE Bild 7: Zugriffsmechanismus bei OLE 2 Automation Die Bilder 8 und 9 zeigen konkret am Beispiel des ersten am Markt verfügbaren busunabhängigen OLE-Tools, wie Anwendungsprogramme auf OLE-Treiber zugreifen. Zur Laufzeit
wird dabei die Programmkontrolle explizit an den OLE-Treiber (auch Objektanwendung genannt) übergeben. Bild 9: OLE-Feldbus-Zugriff am Beispiel VIGO (Proces-Data) Das OLE-Verfahren muß aufgrund seiner höheren Leistungsfähigkeit als das Verfahren der Zukunft angesehen werden. Insbesondere die forcierte Unterstützung innerhalb Windows 95 mit einem reinen 32-Bit-OLE läßt diese Prognose zu. Weiterhin verwendet auch das bekannte RACKS-Projekt - in welchem die Firmen Proces-Data, Softing und Cegelec für die Busse der EN 50170 eine gemeinsamen Anwenderzugriff entwickeln - dieses Verfahren. 6. Verfügbarkeit Da DDE und OLE aufgrund ihrer Offenheit die für die Windows-Welt sinnvollsten Verfahren darstellen, sind in Bild 10 nochmals einige Ausagen zur Verfügbarkeit entsprechender Produkte getroffen. Die Mehrzahl der Produkte findet sich derzeit sicherlich noch im Bereich von DDE- Anwendungen. Dazu zählen auch durch die Verwendung kompakterer Datenformate in ihrer Reaktionszeit verbesserte DDE-Verfahren (wie fastdde von Wonderware). Es ist jedoch ein deutlicher Trend in Richtung OLE festzustellen. An dieser Stelle sei auf die durch die Verwendung von OLE mögliche enge Verzahnung
Bild 10: Verfügbarkeit von DDE und OLE von feldbusbasierter Meßdatenerfassung und Prozeßautomatisierung einerseits sowie der MS-Office-Programme zur Prozeßdatenauswertung und -weiterverarbeitung andererseits hingewiesen. Insbesondere die hohe Leistungsfähigkeit von OLE-Datenverbindungen unter Windows 95 und Windows NT machen diese Verzahnung interessant. Die objektorientierte Arbeitsweise von OLE folgt der objektorientierten Programmierung, wie sie im Bereich der Stand-alone-Programmierung als auch der in Standard-Paketen integrierten Programmiertools (z.b. Visual Basic in Excel) zum Standard wurde. Prof. Dr.-Ing. Jörg Böttcher, Universität der Bundeswehr München / b-plus Meßsysteme GmbH, Tel. 0991/340-897, Fax 0991/340-447, E-mail b-plus@t-online.de