Middleware zur Realisierung offener Steuerungssoftware für hochdynamische Prozesse

Transkript

1 it 1/2004 Middleware zur Realisierung offener Steuerungssoftware für hochdynamische Prozesse Realizing Open Control Software for High Dynamic Processes with a Middleware Karsten Diethers, Bernd Finkemeyer, Nnamdi Kohn, TU Braunschweig Zusammenfassung Middlewarelösungen haben sich in der Praxis bewährt, da sie einen transparenten Softwareentwurf und einen dynamischen Austausch von Softwarekomponenten ermöglichen. Bisherige Ansätze sind für viele Echtzeitanwendungen zu aufwändig und können nicht den Datendurchsatz von hochdynamischen Anwendungen leisten. Daher wird hier mit MiRPA eine leichtgewichtige, echtzeitfähige Middleware vorgestellt, die entsprechend hohe Datenraten erlaubt. Kernstück der Kommunikationsarchitektur ist ein Object Server, der Kommunikationsdienste, wie Nachrichten und kontrollierten Zugriff auf Shared Memory, bereitstellt. Ein auf IEEE1394-Standard (Firewire) aufsetzendes echtzeitfähiges Hochgeschwindigkeitsprotokoll (IAP) erlaubt den Zugriff auf verteilte Komponenten. MiRPA wurde insbesondere für den Einsatz innerhalb von Robotersteuerungen konzipiert und implementiert. Summary Middleware concepts have proven practical relevance. The possibility of a transparent software design and a dynamic exchange of components are beneficial for software design and application. Anyway, due to their general applicability standard middleware approaches tend to be too sophisticated for hard real-time applications. So the performance requirements of a high dynamic robot control system described here are not met. In this article a lightweight realtime middleware, MiRPA, is introduced. The core of MiRPA s communication architecture is an object server, which implements communication services. A high speed communication protocol (IAP) based on the IEEE1394-standard (Firewire) enables data exchange with distributed components. MiRPA is designed and implemented especially for the requirements of high-dynamic robot controls. KEYWORDS C.4 [Performance Assistance] Middleware, Kommunikationsprotokoll, Robotersteuerung, IEEE Einleitung Modularisierung von technischen Systemen bringt Vorteile mit sich. Funktionskomponenten können leicht ausgetauscht und in anderen Anwendungen übernommen werden. Erweiterungen sind leicht realisierbar. So ist es zum Beispiel selbstverständlich, dass die PC-Hardware den Bedürfnissen des Anwenders durch das Einsetzen entsprechender Buskarten angepasst werden kann. Auch im Bereich der Software gibt es Bestrebungen zur Modularisierung. Mit der Einführung der objektorientierten Programmierung ist ein wesentlicher Schritt zur Realisierung modularer Software gemacht worden. Fertige Module bzw. Klassen können ausgetauscht werden. Die Modularität dieses Programmierkonzeptes ist aber noch sehr eingeschränkt. Die Schwierigkeit liegt in der Kommunikation der Sofwaremodule untereinander. Es kommt zu einem Netzwerk von Client/Server-Interaktionen. Dieses nimmt häufig komplexe Ausmaße an. Die Systemübersicht ist dadurch eingeschränkt. Ein einfacher Austausch von Softwaremodulen ist nicht ohne weiteres möglich, da das gesamte Systemverhalten inklusive der zeitlichen Kommunikationsabläufe berücksichtigt werden müsste. Dies kann bei umfangreichen Systemen nicht gewährleistet werden. Daher ist auch die Erweiterung it Information Technology 46 (2004) 1 Oldenbourg Verlag 39

2 des Systems schwierig: Kommunikationsschnittstellen müssen zuerst geschaffen werden. Dies führt zu Änderungen an den übrigen Modulen. Daher schafft allein die Unterteilung eines Systems in unterschiedliche Module noch keine wirkliche Modularität. Abhilfe schafft hier die Verwendung einer Middleware. Sie hat die Aufgabe, die verfügbaren Server eines Systems zu verwalten, zu organisieren und deren Dienste für Clients bereitzuhalten. Diese können dann über die Middleware Kontakt zum Server aufnehmen. Hierbei werden alle notwendigen Kommunikationsschritte von der Middleware erledigt. Das hat den Vorteil, dass die Serverimplementierung, die verwendete Hardware und die Kommunikationsart für den Client verborgen bleiben. Die Dienste können von ihm über das Komunikationsinterface der verwendeten Middleware einfach genutzt werden. Der Vorteil liegt auf der Hand: Die installierten Module eines Systems können über ein standardisiertes Interface angesprochen werden. Bild 1 zeigt die Realisierung einer Robotersteuerung bei der Verwendung der Middleware MiRPA. Alle Module kommunizieren dabei über die Middleware. Es gibt inzwischen eine Vielzahl von Middlewarelösungen. Die Bild 1 Struktur einer auf MiRPA basierenden Steuerung. bekanntesten Entwicklungen sind: DCE der Open Software Foundation [12], DIS/HLA des US-Militärs, DCOM von Microsoft [5] und CORBA der Object Management Group (OMG) [3; 11; 13]. Diese Middlewarelösungen wurden für ein breites Anwendungsspektrum konzipiert und versuchen, diesem und dessen Randbedingungen gerecht zu werden. Dies führt aber zu einem enormen Overhead, den sich Echtzeitsysteme, bei denen die Zeitkonstanten in Mikro- bis Millisekundenbereich liegen, nicht leisten können. Zudem führt der Overhead oft zu einer aufwändigen Handhabung der Middleware, was den praktischen Einsatz erschwert. Auch im Bereich der Steuerungstechnik gibt es Bestrebungen der Vereinheitlichung und Modularisierung der Steuerungssoftware. Zu diesem Zweck wurde das OSACA-Projekt mit dem Ziel der Entwicklung einer offenen und modularen Steuerungsplattform ins Leben gerufen. An diesem Projekt waren industrielle und öffentliche Forschungseinrichtungen beteiligt. Herausgekommen ist ein Steuerungskonzept basierend auf einer Middleware. Deren Anwendung beschränkt sich auf die High- Level -Funktionalitäten einer Steuerung [14; 16] und erfüllt nicht die geforderten Echtzeitanforderungen. In der Literatur findet man inzwischen Ansätze, die oben genannte Middlewarelösungen im Bereich der Steuerungstechnik einzusetzen. In [9] wird z. B. ein Telerobotik-System basierend auf CORBA vorgestellt. Diese Anwendungen müssen aber keinen harten Echtzeitanforderungen genügen. Im Bereich der Realzeitsoftware mit Zykluszeiten von einigen Mikro- bis wenigen Millisekunden haben Middlewarelösungen bis heute keine praktische Anwendung gefunden. Hier werden nach wie vor die Kommunikationswege zwischen den Softwaremodulen direkt festgelegt. Der Grund hierfür liegt in der Gefahr, die zeitlichen Randbedingungen zu verletzen. Bei festen Kommunikationsstrukturen ist die QoS (Quality of Service) leichter zu garantieren. Dies führt aber wie oben beschrieben zu unflexibler Realzeitsoftware. Auch die Echtzeiterweiterungen der bekannten Middlewarelösungen, wie z. B. die echtzeitfähige CORBA Version TAO [15], schafften hier bisher keine befriedigende Abhilfe. Sie erfüllt nur annähernd die gewünschten Echtzeitanforderungen und ist für Systeme mit Zeitkonstanten im unteren Mikrosekundenbereich nicht geeignet. Zudem ist sie sehr statisch und erlaubt nicht den flexiblen Austausch von Softwaremodulen zur Systemlaufzeit. Auch die einfache Definition von Broadcastnachrichten ist nicht möglich. Der enorme Speicheraufwand vieler auf CORBA basierender Middlewarelösungen macht den Einsatz im Embedded Bereich schwierig. Um bis hin zur Treiberebene Modularität und Offenheit zu garantieren, wurde von uns die hier vorgestellte offene Steuerungsarchitektur MiRPA (Middleware for Robotic and Process Control Applications) konzipiert und implementiert [6; 7]. Hierbei wurde viel Wert auf Einfachheit und leichte Bedienbarkeit gelegt. Dabei wurde so wenig wie möglich und soviel wie notwendig an Diensten und Funktionalitäten implemen- 40

3 MiRPA Middleware für Echtzeitsysteme tiert. Das bringt Geschwindigkeitsvorteile und leichte Erlernbarkeit mit sich. Trotz der Einfachheit umfasst das System Dienste wie zentrale Deadlockvermeidung, Watchdog, Serververwaltung und Diagnosetools. 2 MiRPA-Konzept In diesem Kapitel werden die wesentlichen Konzepte der Middleware MiRPA vorgestellt. MiRPA wurde als single-threaded Version auf einem zentralen Rechner unter dem Echtzeitbetriebssystem QNX implementiert. Dabei kann MiRPA auf verteilte Komponenten zugreifen. Der Verteilungsmechanismus für MiRPA selbst, der auch eine multi-threaded Version von MiRPA umfasst, ist spezifiziert, jedoch noch nicht vollständig implementiert. Als Programmiermodell wird von einem Softwaresystem bestehend aus kommunizierenden Komponenten ausgegangen, die als eigene Prozesse realisiert werden. Zur Implementierung der Kommunikation zwischen Prozessen kann auf eine MiRPA-API zurückgegriffen werden. 2.1 Nachrichtenübermittlung Die Modulkommunikation kann bei MiRPA auf unterschiedlichen Kommunikationsmechanismen beruhen. Sowohl QNX-Nachrichten als auch der Datenaustausch über Shared Memory oder TCP/IP für nicht echtzeitfähige Netzwerkzugriffe werden unterstützt. MiRPA überwacht dabei die gewählte Kommunikationsart. Für die echtzeitfähige Kommunikation über ein Netzwerk wurde das publisher-subscriber Kommunikationsprotokoll IAP (Industrial Automation Protocol) konzipiert. Dessen Leistungsumfang wird im Abschnitt 3 vorgestellt. Zur echtzeitfähigen Prozess-Synchronisation auf dem zentralen Rechner wird über MiRPA ein Token-Passing-Mechanismus angeboten. Dieser arbeitet unabhängig und parallel zur asynchronen Kommunikation, ist ihr aber in der Priorität übergeordnet. 2.2 Anmeldephase Beim Start eines auf MiRPA basierenden Sofwaresystems muss als erstes der MiRPA-Kern, der Object Server, gestartet werden. Damit stehen dem Benutzer die grundlegenden Dienste der Middleware zur Verfügung. Sie können über spezielle Kommandonachrichten aktiviert werden. Dazu gehört z. B. das Auflisten der im System bereitgestellten Dienste. Der Benutzer oder ein schon gestarteter MiRPA-Prozess kann daraufhin entscheiden, ob noch weitere Dienste durch entsprechendes Starten von Prozessen bereitgestellt werden müssen. In einer Initialisierungsdatei kann der Anwender bestimmten Nachrichten auch Betriebssystemkommandos zuordnen. Der Benutzer kann somit über die MiRPA-Schnittstelle auf Dienste des Betriebssystems zurückgreifen. Ein neu gestarteter Prozess muss seine Dienste zunächst beim Object Server anmelden. Dabei werden in einer Serverliste die angemeldeten Dienste (bzw. Nachrichtennamen) einem Servermodul zugeordnet. 2.3 Betriebsphase Während des Betriebs senden die Softwaremodule ihre Nachrichten direkt an den Object Server. Wenn z. B. der Trajectory-Planner aus Bild 1 eine neue Position berechnet hat, schickt er eine Nachricht mit dem Namen POSITION. Der Object Server prüft daraufhin, ob ein Server diese Nachricht angemeldet hatte. Falls das der Fall ist, bestätigt er die Weiterleitung. Ansonsten wird eine Fehlermeldung zurückgesendet. Im nächsten Schritt wird die Nachricht an den ermittelten Server weitergeleitet. Wurden mehrere Server für die Nachricht gefunden, wird sie an alle gesendet. Somit ist auch die Definition von Broadcastnachrichten möglich. Bisher wurde nur der Versand von Nachrichten vom Client zum Server beschrieben. Dabei wurden keine Antworten vom Server erwartet. Es sind aber auch Request Mechanismen möglich, die eine Antwort erwarten. Sie funktionieren sehr ähnlich. Ein Request bietet die Möglichkeit, Daten von anderen Komponenten zu erfragen. Der Objekt Server bestätigt die Anfrage und leitet sie automatisch an den zugehörigen Server weiter. Die Kommunikation mit ihm wird aber sofort nach der Weiterleitung beendet. Damit ist der Object Server für andere Module wieder einsatzbereit. Ein langsamer Serverprozess blockiert somit nicht mit langen Antwortzeiten das gesamte System. Der Object Server verwaltet den Request in einer Requestliste und vergibt für ihn eine eindeutige Request-ID. Diese wird dem Client in der Bestätigung zurückgesendet. In der Requestliste merkt sich der Object Server alle noch nicht beantworteten Requests. Der Client ist nach dem Empfang der Bestätigung nicht mehr blockiert und kann andere Aufgaben bearbeiten. Dies könnte z. B. der Versand weiterer Requests an andere Server sein. Auf diese Weise könnten für einen Client mehrere Anfragen parallel bearbeitet werden. Sobald die Ergebnisse benötigt werden, kann der Client die Antwort beim Object Server abrufen. Dieser prüft dann, ob der zugehörige Server bereits geantwortet hat. Liegt eine Antwort vor, wird sie sofort an den Client gesendet. Im anderen Fall gibt es für den Client zwei Möglichkeiten: Er kann blockierend auf die Antwort warten oder er erfragt sie erneut zu einem späteren Zeitpunkt. Der Server antwortet mit einer speziellen Antwortnachricht. Sobald nun der Object Server eine solche Nachricht empfängt, sucht er den zugehörigen Client in der Requestliste und leitet die Antwort an ihn weiter oder hält sie für ihn bereit. Dieses Requestprotokoll ist in dem Bild 2 als Sequenzdiagramm dargestellt. Mit der Requestliste wird verhindert, dass ein Prozess gleichzeitig als Client und Server agieren kann. Ein Request wird nur weitergeleitet, wenn der angesprochene Server zu dem Zeitpunkt nicht auf eine Antwort wartet. Zyklische Blockaden 41

4 Bild 2 Sequenzdiagramm für Request: Client blockiert. Client stellt Request Client erfragt Antwort und blockiert CL:Client Blocked werden verhindert. Vor der Weiterleitung eines Nachrichtenobjektes wird der Zustand des Empfängers überprüft. Dadurch wird verhindert, dass der Object Server durch Sendeversuche an nicht empfangsbereite Prozesse blockiert wird. Die Nachrichten werden in solchen Fällen zunächst gepuffert und später weitergeleitet. Die Aktivität des Object Servers wird von einem Watch-dog überwacht. Falls das Weiterleiten einer Nachricht zu viel Zeit in Anspruch nimmt, wird das Senden abgebrochen und die Nachricht ebenfalls gepuffert. Es sei an dieser Stelle angemerkt, dass die erwähnten Wartezeiten hier im Mikrosekundenbereich liegen und sich allenfalls als kleines Jittern bemerkbar machen. Sie wurden in installierten MiRPA- Systemen empirisch untersucht. Die Ergebnisse werden in Abschnitt 5 vorgestellt. 2.4 Abmeldephase Bei der Beendigung eines Serverprozesses muss sich dieser beim Object Server abmelden. Dieser löscht dann automatisch alle für den beendeten Server registrierten Objekte aus der Serverliste. Die weitere versehentliche und damit fehlerhafte Nutzung wird dadurch verhindert. Das Anund Abmelden von Kommunikationsobjekten kann zu jedem Zeitpunkt auch während der Laufzeit geschehen. Das bedeutet, dass sich eine auf MiRPA basierende Steuerung während des Betriebs an neue Gegebenheiten anpassen kann. Beispielsweise kann sich ein mobiler MsgSend(REQ) MsgReply(OK) MsgReceive MsgSend(ANS) Objektsrv MsgSend(REQ) MsgReply(OK) MsgSend(ANS) MsgReply(OK) SV:Server Objektsrv leitet Request weiter Server antwortet Roboter bei einem stationären Manipulator an- und abmelden. Die Manipulatorsteuerung kann so die Ressourcen des mobilen Kollegen nutzen und so eventuell dessen Stellung korrigieren. 3 MiRPA und verteilte Systeme In zentral organisierten steuerungstechnischen Applikationen, wie sie z. B. in der Robotertechnik existieren, besteht die Notwendigkeit, auch dezentral verteilte Systemkomponenten, wie z. B. intelligente Antriebe oder Sensoren anzukoppeln. Gerade bei Anwendungen, die Nutzdaten echtzeitfähig berechnen und verteilen, sind konstante Zykluszeiten unabhängig vom tatsächlichen Datenumfang einzuhalten. Ein Kommunikationssystem muss diese Anforderungen ebenfalls erfüllen. Es existieren einige serielle Bussysteme, die in der industriellen Kommunikation (z. B. SERCOS, MACRO, Industrial Ethernet), speziell in der Automobilindustrie (z. B. CAN und TTP) oder aber im Multimedia-Bereich (z. B. USB und IEEE1394) zur Übertragung von Nutzdaten in Echtzeit-Anwendung eingesetzt werden. Jedoch sind entweder die zur Verfügung stehende Bandbreite oder der Determinismus für echtzeitfähige Anwendungen mit Zykluszeiten im Bereich weniger hundert Mikrosekunden nicht ausreichend, oder aber es existiert noch kein industrietaugliches Übertragungsprotokoll. Neben einer TCP/IP-Verbindung als eine Form der externen, seriellen Kommunikation wird darum ein zusätzliches echtzeitfähiges Kommunikationssystem benötigt. Bild 3 zeigt die verschiedenen Kommunikationsmechanismen, die MiRPA derzeit auszeichnen. Als Beispiele sind hier das QNX-Message-Passing, welches zur asynchronen Kommunikation innerhalb eines lokalen Rechners genutzt wird, eine TCP/IP Verbindung für externe asynchrone Daten und das IAP für externe echtzeitfähige Nutzdaten aufgeführt. Letztere werden allerdings nicht mittels asynchroner Mechanismen von MiRPA an die entsprechenden lokalen Prozesse übertragen, sondern nutzen geschützte Shared Memory Bereiche, die zyklus-synchron gelesen bzw. geschrieben werden. Im Folgenden soll anhand des IAP gezeigt werden, wie MiRPA durch modulare Erweiterungen auch in verteilten Systemen eingesetzt werden kann. In Bild 4 sind noch einmal die wichtigsten Anforderungen an ein echtzeitfähiges Kommunikationssystem dargestellt. Sie ergeben sich aus den regelungstechnischen Erfordernissen bei Antriebsmoment- Regelung über den Kommunikationsbus. Je größer die Anforderung, desto weiter außen befindet sich der jeweilige Schnittpunkt der Anforderungsfläche mit den Kriterienachsen. In Bild 4 sind die Anforderungen mit einem Hochgeschwindigkeits-Kommunikationssystem in Deckung gebracht wor- Externe Datenübertragungsmöglichkei- Bild 3 ten. 42

5 MiRPA Middleware für Echtzeitsysteme Bild 4 Netzdiagramm zur Beurteilung des Firewire Standards. den. Die schwarzen Linien bezeichnen die Übereinstimmungen mit den beiden separat aufgeführten Versionen des IEEE1394-Standards (Firewire) [2; 8]. Dieser Kommunikationsstandard schien bezüglich der Anforderungen hinsichtlich Bandbreite, Determinismus und Synchronität am besten geeignet. 3.1 Das Industrial Automation Protocol Das IAP [4] ermöglicht nun den effizienten Einsatz des IEEE1394- Standards für Aufgaben, die ein besonderes Maß an Taktsynchronität, Datenquerverkehr und einen hohen Datendurchsatz erfordern. Erst durch die Kombination des IEEE1394-Standards mit dem IAP wird dieses Kommunikationssystem für den industriellen Bereich sinnvoll nutzbar. Die folgenden Erweiterungen werden für die Kommunikation im IAP definiert: Teilnehmerklassen und deren Funktionalitäten. Aufteilung zyklischer Kanäle für Sollwerte, Istwerte und zyklische Datenquerverkehrbeziehungen. Protokollbezogene Interpretation der Telegrammblöcke. Nutzung der asynchronen Datenübertragung. Definition eines Netzwerkmanagements zur Zustandssteuerung jedes Teilnehmers. Zusammenfassung der Teilnehmerparameter in einem Objektverzeichnis. Definition von Parametern für einen hochgenauen, synchronen Betrieb der Netzwerkteilnehmer. Möglichkeiten zur Funktionsüberwachung des Applikationsmasters und der Slaves. Unterstützung von Teilnehmern mit eingeschränktem Funktionsumfang. Möglichkeiten zur Begrenzung der Teilnehmerbelastung durch den zyklischen Datenstrom. Ein vollständiger Übertragungszyklus des IAP ist in Bild 5 darge- Bild 5 Übertragungszyklus und Zeitparameter des IAP. stellt. Jeder Zyklus ist genau 125 µs lang, der Zyklusstart wird über ein CST (Cycle Start Telegram) signalisiert. Das IAP definiert und überträgt in seinem zyklischen Prozess- Datenkanal zwei Telegramm-Typen auf dem Bus: Ein MDT (Master Data Telegramm) hierin werden die neuen Sollwerte von der zentralen Steuerung zu den verteilten Teilnehmern in Form eines zusammenhängenden Datentelegramms übertragen. Mehrere DDT (Device Data Telegramme) hierin werden die Istwerte der verschiedenen Teilnehmer zurück an die zentrale Steuerung übertragen. Zusätzlich wird ein Datenkanal für den Austausch von Steuerdaten innerhalb des Netzwerkes definiert. Eine wesentliche Eigenschaft des IAP ist das Ermöglichen von netzwerkweit taktsynchronen Anwendungen. Dies wird durch globale zyklusbezogene Zeitparameter realisiert (Bild 5). Die auf dem Bus übertragenen Telegramme werden zu festgelegten Zeiten, relativ zum Start eines jeden Zyklus, als gelesen vorausgesetzt. So ergeben sich 43

6 feste Zeitpunkte zum Lesen der Eingänge und Setzen der Ausgänge in den Teilnehmern, aber auch zum Triggern der Applikation im Master. Istwerterfassung, Übertragung und Sollwertvorgabesinddamittaktsynchron zum Regler. 4 Modellierung und formale Analyse Der Object Server von MiPRA nimmt eine zentrale Rolle innerhalb eines Softwaresystems ein. Wird der Object Server beispielsweise für eine Bewegungssteuerung eines Roboters eingesetzt, führen Fehlfunktionen zum sofortigen Ausfall der Steuerung mit drohenden Schäden an der mechanischen Struktur. Die Entwicklung sicherheitskritischer Softwarekomponenten verbunden mit harten Echtzeitbedingungen ist eine große Herausforderung. In den letzten Jahren wurde in der Softwaretechnik die Entwicklung von Methoden vorangetrieben, um das Risiko einer Fehlfunktion zu minimieren. Bei der Entwicklung des Object Servers wurden zwei Vorgehensweisen angewendet, um das Risiko von Spezifikationsfehlern zu reduzieren. Einerseits wurde die Unified Modeling Language (UML) für eine standardisierte Softwarespezifikation eingesetzt. UML ist eine Notation zur objektorientierten Beschreibung von Software. Innerhalb der UML werden informelle und halbformale Diagrammarten gemischt, um Analyse und Design auf verschiedenen Abstraktionsebenen zu unterstützen. Andererseits wurden formale Verifikationstechniken angewendet, um Spezifikationsfehler zu ermitteln, die aus komplexen Abläufen resultieren. Dabei wurde auf die in anderen Projekten erfolgreich angewendete Technik der Modellüberprüfung (Model Checking) zurückgegriffen. 4.1 Modellierung mit UML Die Spezifikation des Object Servers wurde mit Hilfe der UML erstellt. Da der Object Server als generische Kommunikationsplattform eingesetzt werden soll, ist eine DokumentationinstandardisierterNotation notwendig. Die UML Spezifikation enthält vor allem eine Beschreibung des Programmier-Interfaces und des Protokolls von Kommunikationsdiensten mit Hilfe von Szenarien und Zustandsdiagrammen. Eine derartige Spezifikation macht den Entwurf transparent und schafft die Voraussetzung für eine weitergehende Analyse. 4.2 Verifikation Reaktive Systeme erzeugen oft einen gewaltigen Zustandsraum. Unter einem Zustand wird hier die Belegung aller Variabeln, der Zeit, usw. verstanden. Ist kontinuierliche Zeit für das Systemverhalten wichtig, ist der Zustandsraum sogar unendlich, allerdings existieren hier Techniken, Zeitintervalle zu diskreten Regionen zusammenzufassen [1]. Fehler treten oft nur in sehr speziellen Konfigurationen des Systems auf. Ziel einer formalen Analyse ist, die Fehlerkonfigurationen aufzuspüren. Testen kann effizient Fehler mit hoher Auftrittswahrscheinlichkeit aufspüren, aber keine Fehlerfreiheit in der Spezikation garantieren, da sich Zustandsräume von realen Systemen selten vollständig testen lassen. Daher wurde der Object Server mit Hilfe von Model Checking verifiziert. Model Checking überprüft, ob ein formales Modell des zu entwerfenden Systems Eigenschaften erfüllt, die durch Ausdrücke einer geeigneten Logik beschrieben werden. Es gibt derzeit verschiedene Model Checker, die jeweils unterschiedliche Beschreibungssprachen unterstützen und sich durch die Mächtigkeit der unterstützten Logik zur Definition von zu analysierenden Eigenschaften unterscheiden. Wir haben uns zur Modellierung mit Timed Automata entschieden. 4.3 Timed Automata Da ein Schwerpunkt der Analyse auf Zeitaspekten lag, wurde ein Formalismus ausgewählt, der Möglichkeiten zur Modellierung von Zeit bietet. Weiterhin wird Werkzeugunterstützung zur Analyse benötigt. Daher wurden Timed Automata und das Werkzeug UPPAAL für die formale Analyse ausgewählt [10]. Timed Automata wurden von Alur und Dill als formale Beschreibungssprache für Echtzeitsysteme eingeführt. Hier beziehen wir uns auf die Variante, die in UPPAAL implementiert wurde. Wie endliche Automaten enthalten sie Zustände und beschriftete Transitionen und erweitern sie um kontinuierliche Uhren, die zur Modellierung von zeitlichen Aspekten genutzt werden können. Diese werden in Form von Clock- Variablen eingeführt, deren Werte zurückgesetzt oder in Bedingungen von Transitionen benutzt werden können. Kommunizierende Komponenten werden als Netzwerk von Timed Automata modelliert. Kommuniziert wird über globale Variablen oder über komplementär markierte Transitionen, die gleichzeitig schalten (synchrone Kommunikation). Bild 6 zeigt eine Komponente des formalen Modells, das in UP- PAAL erstellt wurde. Zeit vergeht nur in den Zuständen des Modells. Werden Zustände als committed (c) gekennzeichnet, müssen sie sofort verlassen werden. Transitionen schalten zeitlos. Zeitvariablen, deren Werte als sich kontinuierlich erhöhend angenommen werden, dienen zur Spezifikation zeitlicher Zusammenhänge. Sie können zurückgesetzt werden, um eine neue Zeitmessung zu starten oder um an Zuständen zeitliche Invarianten zu definieren. Weiterhin können sie wie einfache Integervariablen in Guards benutzt werden. Zuweisungen an Variablen sind auf einfache Ausdrücke beschränkt. Kommuniziert wird über synchrone Aktionen (msg[rec]! sendet eine Nachricht an andere Komponeten, msg[self]? empfängt eine Nachricht). Einfache Daten können prozessübergreifend über globale Variablen ausgetauscht werden. Details finden sich in [10]. Eigenschaften, die verifiziert werden sollen, werden in Form von temporaler Logik spezifiziert. Typi- 44

7 MiRPA Middleware für Echtzeitsysteme Bild 6 MiRPA- Komponente in UPPAAL. Bild 7 Visualisierung des Analyseergebnisses. lichst umfassende Überprüfung der Funktionalität wurden generische Benutzerprozesse modelliert. Diese Prozesse enthalten nichtdeterministische Verzweigungen; die Modellierung von MiRPA selbst ist deterministisch gehalten. Bild 8 zeigt einen Ausschnitt der manuellen Modellierung von MiRPA mit Timed Automata. Das vollständige System besteht aus mehreren parallelen Komponenten. Mit Hilfe von UPPAAL konnte nachgewiesen werden, dass das formale Modell der MiRPA-Spezifikation keine Deadlocks enthält. Der korrekte Empfang von Commands und Requests kann garantiert werden 1. In MiRPA werden Nachrichten gepuffert, wenn ein Server nicht unmittelbar verfügbar ist. Wenn die Serverkapazität in Folge eines Entwurfsfehlers des Gesamtsystems zu klein gewählt wurde, lässt sich ein Überlauf des Puffers nicht vermeiden. Innerhalb des formalen Modells können Ausführungszeiten berücksichtigt werden, um eine Prognose für einen Pufferüberlauf zu treffen. Dazu ist allerdings eine formale Modellierung des Kontextes notwendig, in dem MiRPA eingesetzt wird. sche Eigenschaften sind beispielsweise Gibt es einen Ausführungspfad des Systems, der in einem unerwünschten Zustand endet? oder Erreicht das System eine Konfiguration mit einem Deadlock?.WirdvomModel Checker ein Ausführungspfad zu einem Fehlerzustand entdeckt, kann er mit Hilfe des Simulators schrittweise untersucht werden. Weiterhin ist eine Darstellung des Fehlerpfades als Sequenzdiagramm verfügbar (siehe Bild 7). 4.4 Formale Modellierung Für eine Verifikation von MiRPA wird das gesamte geschlossene System benötigt, d. h. es reicht nicht, nur den Object Server zu modellieren, sondern es wird auch ein Modell seiner Umgebung benötigt. In diesem Fall müssen Prozesse, die über MiRPA kommunizieren, modelliert werden. Für eine mög- 5 Experimentelle Untersuchung der MiRPA-Performance Die MiRPA-Performance wurde experimentell untersucht. Dabei wurde die Verzögerungszeit vom 1 Fehler der Hardware oder Implementierungsfehler können selbstverständlich nicht ausgeschlossen werden. Bild 8 SIMULINK-Modell mit Zugriffen auf MiRPA. 45

8 Versand bis zum Empfang einer Nachricht und deren Jittern bestimmt. Für die Messungen wurden spezielle Testclients und Testserver entwickelt. Der Testclient setzt vor dem Senden einer Nachricht einen digitalen I/O-Port auf low. Der Server setzt beim Empfang der Nachricht den I/O-Port wieder auf high. Diese Schaltvorgänge wurden mit einem Oszilloskop zur Messung der Schaltzeiten sichtbar gemacht. Das Experiment wurde auf einem Rechner mit AMP XP Prozessor, der mit einer Frequenz von 1466 MHz getaktet wurde, durchgeführt. Auf ihm liefen neben der Middleware MiRPA und den beiden Messprozessen die komplette grafische QNX Benutzeroberfläche Photon, drei Eingabeshells, I/O-Gerätetreiber für serielle, parallele und Ethernet-Schnittstelle, Internetdaemon und weitere Systemprozesse. Die Gesamtzahl der zusätzlich laufenden Prozesse belief sich auf 40. Die Priorität der Messprozesse wurde hoch gewählt. Dabei kam heraus, dass der I/O-Port für ca. 20,88 µs auf Low-Pegel ist. Dies bedeutet, dass der Versand einer Nachricht nur 20,88 µs benötigte. Interessant ist nun, wie stark die Streuung dieser Zeit ist. Dieses Jittern wurde ebenfalls messtechnisch ermittelt. Bei dieser Konfiguration kam dabei ein maximaler Wert von 1,44 µs heraus. Es befindet sich daher für praktische Steuerungsaufgaben in einem akzeptablen Rahmen. Die Messung wurde für verschiedene Rechner- und Softwarekonfigurationen wiederholt. Zusammenfassend ergibt sich, dass im Mittel für den Versand einer Nachricht über die Middleware MiRPA 30 µs benötigt werden. Das maximale Jittern betrug bei ungünstiger Wahl der Prozessprioritäten akzeptable 12 µs. Diese Messergebnisse zeigen, dass MiRPA gut für Steuerungszwecke einsetzbar ist. Der Einsatz ist auch bei einem nicht optimierten System möglich und hat sich bei Robotersteuerungen im Labor praktisch bewährt. 6 Anwendungsbeispiele Es wurde eine auf MiRPA basierende Robotersteuerung realisiert. Als Rechnerhardware kam ein 800 MHz Pentium III zum Einsatz. Dank der modularen Softwarekonzeption und der Middleware MiRPA ließ sich diese Robotersteuerung einfach durch weitere Module wie einer DLR-Spacemouse, mit der sich der Roboter leicht in die gewünschte Position bewegen lässt, erweitern. Die Steuerungssoftware und deren Verwendung von MiRPA wird in [6; 7] ausführlich beschrieben. Durch die Verwendung von MiRPA ist es ebenfalls möglich, die bestehende Software durch Module numerischer Mathematikprogramme wie MATLAB/SIMULINK zu erweitern. Diese Werkzeuge werden für viele numerische Simulationen eingesetzt. Durch Erweiterung mit dem Realtime Workshop können die Simulationen auch in Echtzeitsysteme eingesetzt werden. Der kanadische Softwarehersteller Opal hat mit der Software RT-Lab ein Werkzeug geschaffen, SIMULINK-Modelle auf einem QNX-Zielrechner zu betreiben. Dieser ist über Ethernet mit einem Windows-Hostrechner verbunden. Von dort aus wird das Zielsystem aus der gewohnten SIMULINK-Umgebung heraus bedient. Das RT-Lab übernimmt dabei die Synchronisation der beiden Rechner. Diese Entwicklungsumgebung wurde nun durch eine Schnittstelle zu MiRPA erweitert. Damit ist es leicht möglich, auf MiRPA basierte Realzeitsoftware durch SIMU- LINK-Modelle zu erweitern. Bild 8 zeigt ein Beispiel dieser Anwendung. Die mit MiRPA beschrifteten Blöcke bilden die Schnittstelle zur Middleware. Die Signale, die in diesen Block führen, werden an MiRPA gesendet und von dort entsprechend an die anderen Softwaremodule weitergeleitet. Ebenso führen die Signalleitungen aus diesem Block kommende Signale von MiRPA an das SIMULINK-Modell. Damit steht ein komfortables Rapid-Prototyping-Werkzeug zur Verfügung. In der implementierten Steuerung kann z. B. das Modul Position Controller durch einen SIMULINK-Regler ersetzt werden. Dieser wird somit in der realen Steuerungsumgebung getestet. 7 Zusammenfassung Es wurde mit MiRPA eine echtzeitfähige Middleware vorgestellt. Anders als bei existierenden Ansätzen wurde der Schwerpunkt bei der Entwicklung auf Datendurchsatz, leichte Handhabung und Kompaktheit gelegt. Dadurch ist MiRPA für den Einsatz in Steuerungs- und Echtzeitanwendungen gut geeignet. Da MiRPA allen Softwarekomponenten eine einheitliche Kommunikationsschnittstelle bietet und alle Nachrichten zentral über einen Object Server verwaltet werden, schafft dieser Ansatz mehr Transparenz beim Entwurf von Software. Zudem können integrierte Sicherheitsmechanismen zur Laufzeit kritische Kommunikationsfehler abfangen. Das vorgestellte Kommunikationsprotokoll IAP ermöglicht echtzeitfähigen Datenaustausch über ein Netzwerk. Damit sind zusammen mit MiRPA auch verteilte hochdynamische Steuerungsarchitekturen realisierbar. Danksagung Dank gilt der DFG, die Teile der Arbeit innerhalb des SFB 562 Robotersysteme für Handhabung und Montage unterstützt hat. Literatur [1] R. Alur, D. Dill: A Theory of Timed Automata. Theoretical Computer Science, Vol. 26, pp , [2] D. Anderson: FireWire System Architecture. Addison-Wesley, [3] Balen, Henry: Distributed Object Architectures with CORBA, Cambridge, [4] G. Beckmann: Ein Hochgeschwindigkeits-Kommunikationssystem für die industrielle Automation. Dissertation, TU Braunschweig, [5] P.E. Chung, Y. Huang, S. Yajnik, D. Liang, J. Shih, C. Wang und Y. Wang: 46

9 MiRPA Middleware für Echtzeitsysteme DCOM and CORBA Side by Side, Step by Step, and Layer by Layer. Webdokument, emerald/dcom-corba/ Paper.html, [6] B. Finkemeyer, M. Borchard, and F.M. Wahl: Robot Control Architecture Based on an Object Server. IASTED Int l Conf. Robotics and Manufacturing, Cancun Mexiko, 2001, pp [7] B. Finkemeyer, M. Borchard: MiRPA: A Middleware for Open Robot Control Systems. Robotik 2002, Ludwigsburg, Germany, pp , [8] IEEE Std , Draft Standard for a High Performance Serial Bus. [9] S.Jia,K.Takase:Internet-Based Robotic Systm Using CORBA as Communication Architecture. Journal of Intelligent and Robotic Systems, 34, pp , [10] K. Larsen, P. Pettersson, W. Yi: UPPAAL in a Nutshell. Int l Journal on Software Tools for Technology Transfer, Vol. 1, Springer-Verlag, [11] Object Management Group, http.// [12] The Open Group: Distributed Computing Environment. Webdokument, dec., [13] Orfali, Harkey, Edwards: Instant CORBA. Addison-Wesley, [14] Final Report OSACA I + II: os2fin4.pdf, [15] Douglas C. Schmidt, David L. Lewine and Sumedh Mungee: The Design of the Tao Real-time Object Request Borker. Computer Communications, Elsivier Science, Volume 21, pp , No 4, [16] W. Sperling und P. Lutz: Enabling Open Control Systems An Introductin to the OSACA System Platform. Robotics and Manufacturing, Vol. 6 ISRAM 97 Montpellier/France, ASME Press New York Dipl.-Inform. Karsten Diethers studierte Informatik an der Universität Hildesheim. Seit 1999 ist er wissenschaftlicher Mitarbeiter bei Prof. Dr. Goltz am Institut für Software der TU Braunschweig, Abt. Programmierung und befasst sich dort mit der Modellierung und Verifikation von Echtzeitsystemen. Adresse: TU Braunschweig, Inst. f. Software, Abt. Programmierung, Mühlenpfordtstr. 23, Braunschweig, Diethers@ips.cs.tu-bs.de 2 Dipl.-Ing. Bernd Finkemeyer studierte Elektrotechnik an der TU Braunschweig. Seit Ende 1998 ist er wissenschaftlicher Mitarbeiter bei Prof. Dr. F. M. Wahl am Institut für Robotik und Prozessinformatik der TU Braunschweig. Dort befasst er sich mit der Entwicklung modularer Steuerungskonzepte. Adresse: TU Braunschweig, Institut für Robotik und Prozessinformatik, Mühlenpfordtstr. 23, Braunschweig, B.Finkemeyer@tu-bs.de 3 Dipl.-Ing. Nnamdi Kohn studierte Messund Regelungstechnik an der TU Braunschweig. Seit 2000 ist er wissenschaftlicher Mitarbeiter bei Prof. Dr.-Ing. J.-Uwe Varchmin am Institut für Elektrische Messtechnik und Grundlagen der Elektrotechnik. Dort befasst er sich mit Kommunikations-Konzepten für echtzeitfähige verteilte Systeme. Adresse: TU Braunschweig, Inst. für Elektrische Messtechnik, Hans-Sommer-Str. 66, Braunschweig, Nnamdi.Kohn@tu-bs.de 47