Forschung > Projekte > DCOM und Echtzeit

DCOM und Echtzeit

Beteiligte an der Hochschule

  • Prof. Dr. Reinhold Kröger
  • Dipl.-Inform. (FH), M.Sc. Marcus Thoss

Kooperationspartner

  • Siemens AG A&D, Nürnberg

Laufzeit

Beginn: Februar 1999
Ende: Dezember 2000

Finanzierung

  • 100% Siemens AG A&D

Veröffentlichungen

  • Reinhold Kröger, Marcus Thoss: "DCOM und Echtzeit - Studie", Technischer Bericht, Fachhochschule Wiesbaden, Fachbereich Informatik, 1999.
  • Reinhold Kröger, Marcus Thoss: "DCOM und Echtzeit - Experimentelle Untersuchungen", Technischer Bericht, Fachhochschule Wiesbaden, Fachbereich Informatik, 2000.

Kurzbeschreibung

Offene verteilte Systemstrukturen sowie das objektorientierte Programmierparadigma werden für automatisierungstechnische Anwendungen immer wichtiger. Aufgrund der starken Verbreitung von Betriebssystemen der Microsoft Windows-Familie in der Automatisierungstechnik besitzt die proprietäre Microsoft DCOM-Technologie (Distributed Component Object Model) große Chancen, einen Middleware-Standard für die Automatisierungstechnik zu setzen. Beispielhaft sei etwa auf die Verwendung von DCOM im Rahmen der PROFInet-Festlegungen verwiesen.
Verteilte, Middleware-basierte Anwendungen mit Echtzeitgarantien sind prinzipiell nur erreichbar, wenn über alle Systemebenen hinweg, d.h. von der Anwendungsebene über Middleware- und Betriebssystemebene bis zur Netzwerkebene, Echtzeitaspekte in Design und Implementierung berücksichtigt werden. Will man die Microsoft DCOM-Technologie nutzen, ergeben sich aufgrund der Proprietät von Betriebssystem- und Middleware-Schicht gangbare Schritte zunächst für die unterlagerte TCP/IP-basierte Netzwerkebene. Auf Anwendungsebene bestehen Freiheiten nur in der Art und Weise, wie die DCOM-Funktionalität im Rahmen der vorhandenen APIs in Anspruch genommen wird.
Im Rahmen des mehrphasigen Projekts wurde zunächst in einer Studie nach Möglichkeiten gesucht, die Echtzeiteigenschaften der DCOM-Kommunikation insbesondere bei auftretenden Störlasten durch Anwendung weiterer Internet-Standards zu verbessern. Das Resource Reservation Setup Protocol (RSVP), RFC 2205 u.a., wurde als einziges relevantes Protokoll für den betrachteten Kontext und die Aufgabenstellung identifiziert, auch wenn es auf den Bedarf von Multimedia-Anwendungen zurückgeht. Es erlaubt durch Reservierung von Betriebsmitteln entlang der Kommunikationspfade der DCOM-Komponenten Echtzeiteigenschaften für die Nachrichten zu erreichen, die DCOM-Methodenaufrufe transportieren. Quality of Service (QoS)-basierte Kommunikation auf der Basis von RSVP kann dabei für das Betriebssystem MS Windows 2000 durch dessen sogenannte GQOS-Technologie (Generic Quality of Service) erreicht werden. Für die Anwendungsebene wurde ferner betrachtet, welche Schnittstellen die DCOM-Programmierung in Hinblick auf eine Optimierung/Flexibilisierung und eine RSVP-Awareness bietet. Es zeigte sich, daß die ohnehin schon hohe Komplexität der DCOM-Programmierung weiter ansteigt.
Zur Abschätzung der Praxisrelevanz wurden im Rahmen einer weiteren Projektphase umfangreiche experimentelle Arbeiten durchgeführt. Der Experimentaufbau ist in Abb. 1 verdeutlicht. Zunächst wurde ein Meßmodell mit den interessierenden Kenngrößen, insbesondere Ende-zu-Ende-Verzögerungszeit zwischen Client und Server und Jitter bei periodischen Aufrufen, mit den betrachteten Einflußgrößen und dem angenommenen Lastmodell aufgestellt.
Für die Durchführung der Messungen wurde ein interferenzarmes hybrides Meßsystem entwickelt, bestehend aus einem Logic Analyzer als Meßwertaufnehmer, Windows-Kernel-Treibern zur Generierung von Parallel Port-Signalen für den Logic Analyzer sowie Instrumentierungscode zum Aufruf des Treibers an den relevanten Stellen der Anwendung. Das Meßsystem erlaubt im Gegensatz zu anderen Ansätzen, die ausschließlich Mittelwertbetrachtungen ermöglichen, die Verfolgung jedes einzelnen DCOM-Aufrufs über Rechnergrenzen hinweg unter Nutzung globaler Zeitmarken durch den Logic Analyser.
Ferner wurde eine automatische Experimentsteuerung realisiert, um die insgesamt mehr als 1000 Meßreihen verläßlich durchzuführen. Somit entstand eine Architektur (Abb. 2), an deren Spitze sich eine übergeordnete Visual Basic-Steueranwendung befindet, die sowohl (indirekt) den Logic-Analyzer, den Lastgenerator als auch die zu vermessenden Komponenten des Experiments steuert. Zur Speicherung, Aufbereitung und Auswertung der Meßdaten wurde Microsoft Excel eingesetzt. Damit war es letztlich möglich, aus einem Formular heraus die Steuerung des Experiments und der Datenerfassung sowie die Übertragung der Daten aus dem Logic Analyzer vollautomatisiert durchzuführen.
Insgesamt zeigten die Experimente, daß ein Aufbau von RSVP-kontrollierten Übertragungen mit Windows 2000 grundsätzlich möglich ist und das zeitliche Verhalten der DCOM-Kommunikation in belasteten Netzen sowohl in Hinblick auf die Ende-zu-Ende-Verzögerungszeit als auch in Hinblick auf deren Varianz deutlich verbessert (Abb. 3). In weniger belasteten Umgebungen konnte außerdem kein ausgeprägt negativer Einfluß durch Verwendung von RSVP festgestellt werden. Einzelne auftretende "Ausreißer" unter den Meßwerten zeigen aber, daß auch mit RSVP keine Gewähr für die Einhaltung einer oberen Zeitschranke geleistet wird.