Software-intensive verteilte Echtzeitsysteme Echtzeit 2009: Fachtagung des GI GMA-Fachausschusses Echtzeitsysteme (real-time) Boppard, 19. und 20. November 2009 (Informatik aktuell)

Informatik aktuell Herausgeber: W. Brauer im Auftrag der Gesellschaft für Informatik (GI)

Informatik aktuell

Wolfgang A. Halang Peter Holleczek (Hrsg.)

Software-intensive verteilte Echtzeitsysteme Fachtagung des GI/GMA-Fachausschusses Echtzeitsysteme (real-time) Boppard, 19. und 20. November 2009

 

Herausgeber Wolfgang A. Halang Fernuniversität in Hagen Lehrstuhl für Informationstechnik, insb. Realzeitsysteme 58084 Hagen [email protected]

Peter Holleczek Regionales Rechenzentrum der Universität Erlangen-Nürnberg Kommunikationssysteme Martensstraße 1, 91058 Erlangen [email protected]

Programmkomitee R. Arlt J. Bartels R. Baumgartl B. Beenen J. Benra F. Dressler G. Frey W. Gerth W. A. Halang H. Heitmann P. Holleczek J. Jasperneite R. Müller G. Schiedermeier U. Schneider H. F. Wedde H. Windauer D. Zöbel

Hannover Krefeld Dresden Lüneburg Wilhelmshaven Erlangen Kaiserslautern Hannover Hagen Hamburg Erlangen Lemgo Furtwangen Landshut Mittweida Dortmund Lüneburg Koblenz

Bibliographische Information der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

CR Subject Classification (2001): C3, D.4.7 ISSN 1431-472-X ISBN-13 978-3-642-04782-4 Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer Berlin Heidelberg New York Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2009 Printed in Germany Satz: Reproduktionsfertige Vorlage vom Autor/Herausgeber Gedruckt auf säurefreiem Papier SPIN: 12770779 33/3142-543210

Vorwort

Die im Vorjahr vollzogene Umbenennung des traditionell immer Ende November oder Anfang Dezember in Boppard stattfindenden Workshops des gemeinsamen Fachausschusses Echtzeitsysteme der Gesellschaft für Informatik und der VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik von „PEARL 20XX“ in „Echtzeit 20XX“ und die damit einhergehende Erweiterung des Themengebietes auf den gesamten Bereich der Echtzeit- und eingebetteten Systeme ist offensichtlich „am Markt“ gut aufgenommen worden. Das zeigt die deutlich erhöhte Anzahl von Vortragseinreichungen und daraus resultierend die leider ebenfalls erhöhte Ablehnungsquote. Um die auf der Tagung zur Verfügung stehende Vortragszeit und die im vorliegenden Band maximal mögliche Anzahl von Druckseiten optimal auszunutzen, ohne das vom Fachausschuss verfolgte Ziel der Nachwuchsförderung aus dem Auge zu verlieren, entschied sich das Programmkomitee, in diesem Jahr den drei Preisträgern für studentische Abschlussarbeiten jeweils vier Seiten im Tagungsband zur Vorstellung der Ergebnisse ihrer Arbeiten einzuräumen. Die kurzen mündlichen Präsentationen dieser Beiträge sind zusammen mit der Preisverleihung als Teil des Abendprogramms am ersten Tag der Fachtagung vorgesehen. Dem allgemeinen Trend der Datenverarbeitung folgend, sind auch eingebettete und Echtzeitsysteme zunehmend vernetzt und ihr Software-Anteil wächst sprunghaft an. Wegen der Sicherheitsrelevanz vieler eingebetteter und Echtzeitsysteme gibt diese Entwicklung zur Besorgnis Anlass und war deshalb der Grund, den Workshop dieses Jahr software-intensiven verteilten Echtzeitsystemen zu widmen. Eine Maßnahme zur Beherrschung von Software-Komplexität ist der Einsatz von Entwurfs- und Entwicklungswerkzeugen, wie sie in einer Sitzung der Tagung betrachtet werden. Eine weitere Sitzung beschäftigt sich direkt mit der Kommunikation in verteilten Systemen unter besonderer Berücksichtigung des Aspekts der Echtzeitfähigkeit. Thematisch schließt sich daran sehr eng eine Sitzung zur Leistungsanalyse von und zur Fehlerdiagnose in verteilten Echtzeitsystemen an. Traditionell widmet sich eine Sitzung des Workshops immer aktuellen Echtzeitanwendungen. In diesem Jahr werden solche aus dem Gebiet der Fertigungstechnik vorgestellt. Bevor die Teilnehmer am Abend des ersten Tages der Fachtagung beim Abendessen schließlich auf den Teller blicken, richten sie in der vorausgehenden Sitzung noch ihren Blick über den Tellerrand des Gebietes hinaus auf die zum Management von Ressourcen in Logistik, Operations Research und Biologie verwendeten Methoden. Auch dieses Jahr ist es – zur Freude des Springer-Verlages und der Herausgeber – wieder gelungen, den Tagungsband in einheitlichem Erscheinungsbild zu realisieren. Dazu mussten nur noch ganz wenige Autoren überredet werden, statt des StandardTextverarbeitungsprogramms das sich durch seine viel höhere bibliographische Qualität auszeichnende Formatierungssystem LaTeX zu verwenden. Die Herausgeber bedanken sich bei den Autoren sehr herzlich für die Einhaltung der strikten Begrenzung des Beitragsumfangs, die im Regelfall vorzeitige Bereitstellung der Beiträge und die

VI

Vorwort

reibungslose Zusammenarbeit. So ließ sich dann das druckfertige Manuskript innerhalb weniger Tage fertigstellen. Unser besonderer Dank gebührt deshalb Frau Dipl.-Ing. Jutta Düring, die diese Aufgabe ganz alleine bearbeiten musste, weil der erste Herausgeber durch eine Augenoperation außer Gefecht gesetzt war. Frau Düring hat aber den Tagungsband nicht nur formatiert, sondern sogar noch orthographische Fehler korrigiert und im Druck schlecht wirkende Abbildungen neu gezeichnet. Programmkomitee und Leitungsgremium des Fachausschusses danken den industriellen Sponsoren sehr herzlich für die finanzielle Unterstützung des Workshops und wünschen den Teilnehmern der Fachtagung einen intensiven und anregenden Meinungsaustausch, eine schöne Zeit in Boppard sowie den Lesern des vorliegenden Bandes eine interessante Lektüre.

Hagen

Erlangen

im August 2009 Wolfgang A. Halang

Peter Holleczek

Inhaltsverzeichnis

Kommunikation in verteilten Echtzeitsystemen Ein Framework für echtzeitfähige Ethernet-Netzwerke . . . . . . . . . . . . . . . . . . . . . Dr. Frank Dopatka

1

UniLoG – ein System zur verteilten Lastgenerierung in Netzen . . . . . . . . . . . . . . Andrey Kolesnikov, Bernd E. Wolfinger, Martin Kulas

11

Planning of Time Triggered Communication Schedules . . . . . . . . . . . . . . . . . . . . Olaf Graeser, Oliver Niggemann

21

Engineering-Werkzeuge für Echtzeitsysteme Raum-Zeit-Constraints als Programmierabstraktion für Anwendungen in mobilen verteilten Systemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Martin Däumler, Dirk Müller, Matthias Werner

31

Formale Bestimmung von Systemparametern zum transparenten Scheduling virtueller Maschinen unter Echtzeitbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . Timo Kerstan, Daniel Baldin, Gunnar Schomaker

41

Methoden des Ressourcen-Managements Anwendung von Methoden der Logistik und Netzplantechnik zur präzedenzund ressourcenbeschränkten Ablaufplanung von Echtzeitsystemen . . . . . . . . . . . Roman Gumzej, Martin Lipiˇcnik

49

Bienen-inspiriertes Straßenverkehrsrouting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sebastian Senge, Sebastian Lehnhoff, Anca M. Lazarescu

57

Studentische Beiträge Schichtübergreifende Früherkennung von Verbindungsausfällen in drahtlosen Mesh-Netzwerken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Timo Lindhorst

67

Konzept zur Übertragung von Daten in verteilten Echtzeitsystemen via Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Werner Pirkl

71

Echtzeitfähigkeit des VxWorks Netzwerkstacks . . . . . . . . . . . . . . . . . . . . . . . . . . Stefan Zeltner

75

VIII

Inhaltsverzeichnis

Fertigungstechnische Anwendungen Kommunikationsanforderungen an verteilte Echtzeitsysteme in der Fertigungsautomatisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Roman Just, Henning Trsek

79

XML-basierte Produkt- und Prozessdaten für die Leittechnik-Projektierung . . . . Miriam Schleipen

89

Leicht konfigurierbare Hardware-Abstraktionsschicht für flexible Automatisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Uwe Schmidtmann, Gerhard Kreutz, Matthias Barkhoff, Kristian Virkus, Tobias Stöckmann, Marcel Jovic

99

Performance-Analyse und Debugging Universeller hybrider Systembeobachter für Echtzeitsysteme . . . . . . . . . . . . . . . . 109 Björn Pietsch Echtzeitverhalten durch die Verwendung von CPU Stubs: Eine Erweiterung von Dynamic Performance Stubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Peter Trapp, Christian Facchi, Markus Meyer Protokollanalyse und Informationsflussverfolgung zur Fehlerdiagnose in verteilten Echtzeitsystemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Eugen Noak, Silvije Jovalekic, Heinrich Grochowski

Ein Framework für echtzeitfähige Ethernet-Netzwerke Dr. Frank Dopatka GFU Cyrus AG Gesellschaft für Unternehmensberatung, 51105 Köln-Deutz    

Zusammenfassung. Im Rahmen dieser Arbeit wird die Entwicklung eines formalen Framewoks vorgestellt, mit dessen Hilfe zwischen der Kompatibilität zum verbreiteten baumförmigen Standard-Ethernet und der Einhaltung von Echtzeitanforderungen einer automatisierten Anlage variiert werden kann. Damit kann bereits vor der Auswahl einer bestimmten Technologie eine Schedule der EchtzeitÜbertragungen offline kalkuliert und simuliert werden, sobald die Anforderungen der Geräte im industriellen Echtzeit-Netzwerk bekannt sind. Ausgehend von einer stark vereinfachten Modellbildung werden in mehreren Schritten Verfeinerungen vorgenommen, die zukünftig eine nahtlose Integration in existierende industrielle Lösungen ermöglichen sollen.

1 Motivation Im Umfeld der Automatisierungstechnik ist bereits seit einigen Jahren der Trend zu beobachten, etablierte Feldbusse durch echtzeitfähiges Ethernet zu ersetzen oder zu ergänzen. Das Ziel liegt darin, eine einzige Netzwerkinfrastruktur von der Leitebene im Bürobereich bis hin zu Feldgeräten wie Sensoren, Aktoren und Bedienpulten in industriellen Produktionshallen zu schaffen. Dieser Trend wird als vertikale Integration bezeichnet [1]. Ein Hauptproblem liegt dabei darin, dass die weit verbreiteten StandardEthernet Netzwerke nicht den harten Anforderungen der industriellen Echtzeit genügen. So ist bereits in einem kollisionsfreien Vollduplex-Ethernet die Zwischenspeicherung eines Datenpaketes ausreichend, um den Anforderungen der härtesten Echtzeitklasse der Industrial Automation Open Networking Alliance (IAONA) [2] zu widersprechen, bei der die maximale Verzögerung eines Frames im Netzwerk 1ms und die Schwankung dieser Verzögerung – der Jitter – maximal 1μ s beträgt. Andererseits soll jedoch der Ethernet-Standard auch auf der Feldebene eingehalten werden, da ansonsten wiederum separate Feldbusse entstehen. Es existiert bereits eine Reihe von industrie-tauglichen Lösungen für echtzeitfähiges Ethernet, die im folgenden Kapitel kurz vorgestellt und klassifiziert werden. Es lässt sich erkennen, dass jeder Ansatz einen individuellen Kompromiß zwischen den Echtzeitanforderungen aus der Automatisierungstechnik und der Kompatibilität zu Standard-Ethernet darstellt. Die eigene Forschung hat sich nicht zum Ziel gesetzt, einen weiteren dieser Kompromisse hervorzubringen. Statt dessen wird die Grundlage für ein technologie-unabhängiges, mathematisch formales Framework gelegt, das im dritten Kapitel vorgestellt wird. Die Vorgehensweise bei der Entwicklung des Frameworks verläuft von einer stark vereinfachten Mo-

2

F. Dopatka

dellierung und Lösungsfindung schrittweise zu realitätsnäheren Ansätzen. Das Ziel besteht darin, möglichst viele der existierenden Ansätze in dem allgemeinen Framework formal zusammenzufassen. Im dritten Kapitel werden exemplarisch idealisierte Vollduplex-Netze unter Verwendung von Switches betrachtet. Im vierten Kapitel werden dann zwei Verfeinerungen der Modellierung vorgestellt, indem zunächst Hubs und anschließend Verzögerungszeiten in die Modellierung aufgenommen werden. Die Betrachtung endet mit einer Zusammenfassung der erreichten Ergebnisse und mit Perspektiven für die zukünftige Forschung.

2 Stand der Forschung Durch das Fehlen eines deterministischen Medienzugriffs, der Pufferung von DatenFrames in Switches und ggf. sogar deren Verwerfung bei vollen Puffern sowie durch einen hohen Protokoll-Overhead im Vergleich zu Feldbus-Protokollen können härteste Echtzeitanforderungen der Antriebstechnik nicht mit Standard-Ethernet nach IEEE 802.3 umgesetzt werden. Dies beinhaltet insbesondere die Forderung nach Isochronität. Durch die konstanten Perioden isochroner Übertragungen (IRT) sollen mechanische Wellen durch eine zyklische, hoch präzise getaktete Verbreitung der Ist-Werte einer Master-Achse zu ihren Slaves ersetzt werden. Man wünscht sich in diesem Zusammenhang eine „Software-Welle“ [3]. Die IRT-Übertragungen sind in der Automatisierungstechnik im Vorfeld bekannt. Es lässt sich also im Voraus bestimmen, welcher Sensor, Aktor oder welche Steuerung zu welchem Zeitpunkt senden darf. Ebenso kann die maximale Größe der EchtzeitFrames im Vorfeld festgelegt werden. Im Gegensatz zu herkömmlichen Ethernet-Übertragungen, bei denen u. a. Multimedia-Daten oder E-Mails mit Anhängen übertragen werden, werden im industriellen Bereich lediglich einige Bytes an Nutzdaten pro Frame versendet, die zumeist Soll- und Ist-Positionen der Antriebe enthalten. Ein Lösungsansatz besteht darin, eine Modifikation zum Ethernet-Standard oberhalb der Sicherungsschicht vorzunehmen, wie es unter anderem bei dem verbreiteten Ethernet PowerLink (EPL) der Fall ist. Dabei kommen 100MBit/s-Hubs anstelle von Switches zum Einsatz, da die Verzögerungszeiten der Frames bei Hubs um ein Vielfaches geringer sind. Nachteile bestehen darin, dass neben dem Einsatz von veralteten Hubs lediglich eine Kommuniktion zu einem Zeitpunkt im Netzwerk erlaubt ist, da durch die Halbduplex-Übertragung das CSMA/CD-Verfahren mit nicht-deterministischer Backoff-Strategie zum Einsatz kommt. Zusätzlich halbiert der Halbduplex-Betrieb die physikalische Bandbreite des Netzes. Auch zerstören Übertragungen von asynchron sendenden Geräte, die nicht dem EPL-Protokoll folgen, die Echtzeitfähigkeit des Netzes. Ein zweiter Lösungsansatz liegt in der Ersetzung oder Ergänzung der physikalischen Ethernet-Schicht inklusive der Medienzugriffssteuerung. Die Ersetzung hat den Zweck, für die härteste IAONA-Echtzeitklasse optimierte Hardware bereit zu stellen. Als Vertreter dieses Ansatzes existieren ProfiNet IRT, SERCOS III sowie EtherCAT. Der Vorteil der optimierten Hardware für die Automatisierungstechnik spiegelt sich gleichzeitig als Nachteil für die Kompatibilität zum Ethernet-Standard wider.

Ein Framework für echtzeitfähige Ethernet-Netzwerke

3

Aus diesen Ansätzen ist zu entnehmen, dass zwar viele gute und auch effiziente Lösungen existieren, die Lösungen jedoch stets einen konkreten Kompromiß zwischen Kompatibilität zum Standard und den Anforderungen der Automatisierungstechnik darstellen. Das zu erstellende Framework soll die Basis für den flexiblen, anwendungsbezogenen Aufbau von industriell echtzeitfähigen Netzen schaffen.

3 Grundlagen der Modellierung Die Idee der Modellierung besteht darin, im ersten Schritt das zu erstellende Netzwerk formal zu modellieren. Die Position der einzelnen Geräte mit verschieden hohen Anforderungen an die Echtzeit – wie Antriebe, Sensoren und Aktoren – sowie deren Verkabelung lässt sich zum Großteil aus der mechanischen Konstruktion der konkreten Anlage ableiten. Im Anschluß daran werden die Übertragungen mit hohen Echtzeitanforderungen modelliert, die über das Netzwerk verlaufen. IRT-Übertragungen, die gleiche Wege im Netzwerk durchlaufen, dürfen unter Umständen nicht gleichzeitig ausgeführt werden, da dadurch eine erhöhte Verzögerungszeit und insbesondere ein erhöhter Jitter resultieren würde. Zwischen diesen Übertragungen entstehen somit „Konflikte“, die zeitlich zu entzerren sind. Aus den Konflikten wird ein Konfliktgraph gebildet, der durch seine anschließende Färbung die zeitliche Entzerrung vornimmt. Die einmalige Abarbeitung der Schedule ist gleichzusetzen mit einer Umdrehung der „Software-Welle“ in der automatisierten Anlage und stellt einen Produktions-Zyklus dar. 3.1 Idealisierte Vollduplex-Verbindungen Um sich dem komplexen Problem zu nähern, wird im ersten Schritt von einem stark vereinfachten Netz ausgegangen. Dabei wird die ausschließliche Verwendung von idealisierten, nicht blockierenden Switches angenommen. Dies bedeutet, dass bei n Ports im Idealfall n/2 Übertragungen gleichzeitig möglich sind, ohne dass Daten zwischengespeichert oder verworfen werden. Ein auf Switches basierendes baumförmiges Netz arbeitet nach IEEE 802.3 im Vollduplex-Modus, in dem auf einem Ethernet-Kabel gleichzeitig gesendet und empfangen werden kann. Verzögerungszeiten und deren Jitter werden zunächst ignoriert. Des Weiteren werden einheitliche Framelängen angenommen. Die zusätzliche Übertragung von asynchronen Frames wird nicht betrachtet und später in die entstandene Schedule der Echtzeitübertragungen integriert. Es wird ebenso angenommen, dass jede IRT-Übertragung in jedem Sendezyklus auftritt und ausschließlich Unicast-Übertragungen vorliegen. Im ersten Schritt wird die Netzwerk-Infrastruktur als Graph modelliert. Über diesen Graph verlaufen die IRT-Übertragungen, deren Sendezeitpunkte zu planen sind. Das Netzwerk besteht aus einer endlichen Menge von Switches und einer endliche Menge von Geräten, die zu einer Knotenmenge des Netzes zusammengefasst werden. Angeschlossene Geräte bilden die Blätter im Netzwerk-Baum. Zusätzlich dazu existiert eine endliche Menge von Netzwerkkabeln, wobei ein Netzwerkkabel zwischen zwei Knoten als Kante zwischen den verbundenen Knoten repräsentiert wird.

4

F. Dopatka

Ausserdem existiert eine endliche Menge von IRT-Übertragungen, die als Kommunikationslinien bezeichnet werden. Da es sich bei dem Netzwerk um einen Baum handelt, ist der Weg jeder Unicast-Übertragung eindeutig bestimmt. Jeder Kommunikationslinie wird eine einheitliche positive Übertragungsdauer zugeordnet. Jede Kommunikationslinie verläuft von genau einem Quellgerät zu genau einem Zielgerät über einen oder mehrere Knoten des Netzwerkes. Jeder Port eines Switches besitzt einen unabhängigen Eingangs- und Ausgangsteil. Wird ein Daten-Frame zu einem Zeitpunkt an einem Eingangs- oder Ausgangsteil eines Ports übertragen, an dem bereits ein anderer Frame übertragen wird, wird der zweite Frame verkehrsabhängig gepuffert und im Falle der Überlast sogar verworfen. Dies wird im Folgenden als „Konflikt“ bezeichnet, der aufzulösen ist, da die nicht-deterministische, lastabhängige Verzögerungszeit der Frames in harten Echtzeitumgebungen nicht tolerierbar ist. Das Auflösen der Konflikte besteht also darin, dafür zu sorgen, dass die betreffenden Kommunikationslinien nicht zur selben Zeit an den konflikt-trächtigen Knoten im Netz ausgeführt werden. Diese zeitliche Entzerrung bedeutet eine Ablaufplanung der Übertragungen, also die Bildung einer Schedule. Durch die Definition des Konflikt-Begriffes können nun zwei Aussagen getroffen werden, die für die Berechnung der Schedule von Bedeutung sind. Die erste Aussage besteht darin, dass eine lokale Konfliktfreiheit eine globale Konfliktfreiheit impliziert [4, Satz 4.2.4]. Durchlaufen zwei verschiedene Kommunikationslinien einen gemeinsamen Switch und haben dort keinen Konflikt, weil sie nicht in dieselbe Richtung verlaufen, so sind sie global konfliktfrei. Die zweite Aussage besteht darin, dass Konfliktknoten stets einen Weg bilden [4, Satz 4.2.6], also jeweils durch eine eindeutige, zusammenhängende Folge von Knoten miteinander verbunden sind. Im Anschluss an die Modellierung des Netzes und der Übertragungen wird der Kantenkonfliktgraph betrachtet. Die Idee besteht darin, an dieser Stelle auf die Modellierung der Ports eines Switches zurückzugreifen. Die beiden Teile bildet je einen Knoten im Kantenkonfliktgraph. Jede Unicast-Übertragung verläuft von genau einem Eingangsport zu genau einem Ausgangsport und bildet eine Kante im Graphen. Sind mehrere Kanten mit einem Knoten verbunden, so müssen Sie bei einer gültigen Kantenfärbung verschiedene Farben erhalten. Erhalten zwei Kommunikationslinien dieselbe Farbe, so können sie unabhängig voneinander ausgeführt werden. Jede Farbe repräsentiert einen Zeit-Slot in der resultierenden Schedule und die Anzahl der Farben multipliziert mit der Übertragungszeit der Frames die Zykluszeit des Netzes. Eine optimale Färbung bedeutet gleichzeitig eine optimale Schedule mit minimaler Ausführungsdauer. Es wurde bewiesen, dass der Kantenkonfliktgraph eines Vollduplex-Netzwerkes bipartit ist [4, Satz 4.4.8], so dass die Färbung erheblich vereinfacht wird. Zunächst ist bereits bei der Entstehung des Konfliktgraphen bekannt, dass er mit χ  (G) = Δ (G) gefärbt werden kann. Auf diese Weise kann vor der Färbung bereits der Switch definitiv ermittelt werden, der für die meisten Zeit-Slots der Schedule verantwortlich sein wird. Ein einfacher optimaler O(|E| · log(|E|))-Algorithmus zur Färbung bipartiter Graphen stammt von Alon [5] aus dem Jahre 2003.

Ein Framework für echtzeitfähige Ethernet-Netzwerke

5

Die Schedule für einen Switch aus der Netzwerkinfrastruktur lässt sich leicht erzeugen, sofern der gefärbte Konfliktgraph gegeben ist [4, Satz 6.3.1/2]. Man durchläuft alle gefärbten Kanten und sortiert die Anforderungen mit gleicher Farbe Fi jeweils in einen Vektor, der dann einem Zeit-Slot entspricht. Da die lokalen Schedules für jeden Switch unabhängig erstellt werden können, ist es möglich, dass derselben Übertragung in zwei lokalen Schedules verschiedene Zeit-Slots zugewiesen werden. Ein Problem besteht jedoch darin, dass eine Kommunikationslinie, welche über mehrere Switches verläuft, bei unabhängiger Berechnung der lokalen Schedules verschiedenen Zeit-Slots zugeordnet werden kann. Es wurde bewiesen, dass die lokalen Schedules nicht stets zu einer globalen Schedule durch Um-Indizierung der Zuordnungen synchronisiert werden können [4, Satz 6.2.2]. Eine Idee zur Lösung besteht darin, zunächst alle Kantenkonfliktgraphen zu erzeugen und exakt zu färben. Ein Switch mit der größten Anzahl an Farben stellt dann den Wurzel-Switch w für die weitere Färbung dar. Treten IRT-Übertragungen auch in Switches auf, die direkt mit w verbunden sind, so erhalten sie jeweils dieselbe Farbe, wie sie in w besitzen. Im Anschluss daran werden die restlichen Übertragungen des Konfliktgraphen neu gefärbt. Dieser Vorgang wiederholt sich für das gesamte Netzwerk. Auf diese Weise erhält man in einem Schritt synchronisierte Schedules. Der Algorithmus hat Nowak [4, S. 118] formal beschrieben.

4 Erweiterung des Frameworks In diesem Kapitel werden nun zwei Erweiterungen des Frameworks vorgestellt, welche die Modellierung realitätsnäher gestalten. Dazu gehört einerseits die Integration von Hubs in das formalisierte Netzwerk und andererseits die die Berücksichtigung von Verzögerungszeiten in Switches sowie deren Auswirkung auf die erstellten Schedules. 4.1 Einbindung von Hubs An einem Hub existiert zu einem Zeitpunkt maximal eine Übertragung, die von allen angeschlossenen Geräten empfangen werden kann. Eine besondere Situation ergibt sich, sobald ein Hub zusammen mit Switches in einem Netzwerk kombiniert wird. Abbildung 1 zeigt fünf Kommunikationslinien, die zwischen zwei Switches und einem Hub verlaufen. An den Hub ist an Gerät G1 eine Master-Achse sowie 6 Slave-Achsen (G2 bis G7) angeschlossen. Während die beiden Kommunikationslinien 1 und 2 aufgrund des Halbduplex-Betriebes des Hubs sowie an Port 0 von Switch 1 in Konflikt stehen, sind sie in Switch 2, der ausschließlich im Vollduplexbetrieb arbeitet, konfliktfrei. In diesem Fall impliziert die lokale Konfliktfreiheit also keine globale Konfliktfreiheit. Daher ist ein globaler Knotenkonfliktgraph zu bilden, der das gesamte Netzwerk betrachtet (s. Abbildung 1b). Des Weiteren ist zu beachten, dass die dritte Kommunikationslinie auch vom Port 0 des Switches 1 empfangen wird. Trotz der Übertragung innerhalb des Hubs ist der gesamte Port 0 dieses Switches für die Dauer der Übertragung gesperrt. Da der Hub ausschließlich Broadcastsendungen zulässt, kann er als einziges Gerät D∗ im Halbduplex-Betrieb

6

F. Dopatka

angesehen werden. Alle Übertragungen stehen dort in Konflikt zueinander und benötigen einen eigenen Zeit-Slot. Die Färbung kann mit einem beliebigen Färbungs-Algorithmus zur Knoten-Färbung erfolgen. Aus dem knoten-gefärbten Graphen lassen sich die lokalen Schedules der Switches ableiten (s. Abbildung 1c), indem lediglich die IRT-Übertragungen betrachtet werden, die über den betreffenden Switch verlaufen.

Abb. 1: Netzwerk (a), globaler Konfliktgraph (b) und lokale Schedules (c)

4.2 Berücksichtigung von Verzögerungszeiten Die Modellierung ist bislang vereinfachend davon ausgegangen, dass die Knoten des Netzes die IRT-Übertragungen nicht verzögern. Dies ist in der Praxis nicht der Fall. Die Verzögerung eines Hubs liegt in der Praxis sie bei ca. 0.4 μ s [6], die eines ProfiNet Switches bei ca. 3μ s [7]. Modelliert man eine Linientopologie (s. Abbildung 2a) mit 10 Verteilern (S1 bis S10), so ergibt sich eine Verzögerungszeit eines Frames vom sendenden Gerät am Anfang der Linie bis zum letzten empfangenen Gerät am Ende der Linie von 30μ s bei der Verwendung von ProfiNet Switches und 4 μ s bei Hubs. Die Verzögerungszeiten besitzen insbesondere dann einen großen Einfluss auf die erstellte Schedule, wenn von einer minimalen Framegröße ausgegangen wurde, die ca. 7μ s für ihre Übertragung benötigt. Um mögliche Integrationen von Verzögerungszeiten in das Modell zu diskutieren, wird im weiteren Verlauf dieses Kapitels das Beispiel aus Abbildung 2a eines auf Switches basierenden Vollduplex-Netzwerkes mit Unicast-Übertragungen verwendet. Zur besseren Berechenbarkeit wird angenommen, dass alle Verteiler die gleiche Verzögerungszeit TV besitzen. Ein einfacher Ansatz besteht darin, zunächst die globale Sche-

Ein Framework für echtzeitfähige Ethernet-Netzwerke

7

dule zu erstellen. Dies kann über den globalen Knotenkonfliktgraphen in Abbildung 2b geschehen, der greedy-gefärbt wird. Daraus resultiert die globale Schedule in Abbildung 2c, die zunächst keine Verzögerungszeiten berücksichtigt.

Abb. 2: Netzwerk mit Verzögerungen (a), gefärbter globaler Konfliktgraph (b) und globale Schedule (c)

Geht man von einer minimalen Framelänge aus, so beträgt die ideale Zykluszeit 4 · 7 μ s = 28 μ s. Die Verzögerungszeiten der Kabel werden im folgenden Beispiel vernachlässigt. Die IRT-Übertragungen verlaufen über 10 Verteiler mit einer jeweilgen Verzögerungszeit TV . Basierend auf ProfiNet-Switches mit TV = 3μ s ergibt sich eine maximale Gesamtverzögerungszeit von TV,Ges = 30μ s, die für die IRT-Übertragung 1 auch zutrifft, da diese über das gesamte Netzwerk verläuft. Dies bedeutet, das bei Berücksichtigung der Verzögerungszeiten die einzelne Übertragung 1 bereits länger dauert als die gesamte idealisierte Schedule. Erweitert man jeden Slot pauschal um die maximale Verzögerungszeit im Netzwerk zuzüglich der Übertragungszeit TU = 7μ s des Frames, so würde jeder Zeit-Slot TV,Ges + TU = 37μ s lang sein. Die Zykluszeit wird auf diese Weise von 28 μ s ohne Berücksichtigung der Verzögerungen auf 4 · 37μ s = 148μ s erhöht. Die Einordnung der Übertragungen in die globale Schedule nach ihrem frühest möglichen Start-Zeitpunkt stellt eine Optimierung dar. Dies ist mit einem List-Scheduling bzw. einer First-Fit Vorgehensweise zu vergleichen, das aufgrund der im Vorfeld bekannten IRT-Übertragungen offline durchgeführt werden kann. Die Auflösung der Zeit-Slots hat zur Folge, dass eine Färbung des Konfliktgraphen nicht mehr benötigt wird. Die Erstellung des globalen Knotenkonfliktgraphen ist dennoch sinnvoll, um die Konflikte zwischen einzelnen Kommunikationslinien zu erkennen. Ähnlich wie bei der Graphenfärbung werden dabei zunächst die IRT-Übertragungen in einer Reihenfolge vorsortiert. Entsprechend dieser Reihenfolge werden die IRTÜbertragungen nacheinander direkt in die Schedule eingefügt unter der Prämisse der

8

F. Dopatka

möglichst frühen Sendung. Es wird also vom Beginn der Schedule bei 0 μ s untersucht, ob die gerade betrachtete IRT-Übertragung eingefügt werden kann oder nicht. Ist dies nicht der Fall, so wird eine erneute Untersuchung unmittelbar nach Beendigung der Übertragung, mit welcher die betrachtete Übertragung in Konflikt steht, durchgeführt. Dies geschieht so lange über alle Switches, die von der betrachteten IRT-Übertragung betroffen sind, bis ein freier Bereich innerhalb der Schedule gefunden wird. Diese Vorgehensweise ist mit dem Greedy-Algorithmus der Graphenfärbung vergleichbar. Beim Greedy-Algorithmus der Graphenfärbung existiert jedoch stets mindestens eine Vorsortierung, welche zu einem optimalen Ergebnis führt [8]. Eine solche optimale Vorsortierung existiert auch bei der Anwendung des List-Schedulings. Die Aufgabe besteht nun darin, eine optimale Vorsortierung der IRT-Übertragungen zu ermitteln. Nach Abbildung 2b wird zunächt die Anzahl der Konflikte jeder IRT-Übertragung anhand des globalen Knotenkonfliktgraphen ermittelt. Die Anzahl ist jeweils an den Knoten, welche die jeweilige Übertragung repräsentiert, verzeichnet. Im Anschluss daran werden die Übertragungen anhand der Anzahl der Konflikte nacheinander in die Schedule eingefügt, wobei mit der IRT-Übertragung mit den meisten Konflikten begonnen wird. Eine sinnvolle Heuristik besteht darin, die Anzahl der Konflikte der Übertragungen zu zählen, welche noch nicht in die Schedule integriert worden sind und die Knoten der bereits eingefügten Übertragungen mit den inzidenten Kanten aus dem Konfliktgraphen zu entfernen. Dies entspricht einer dynamischen Sortierung und ist mit dem Sättigungsgrad des DSATUR-Algorithmus der Graphenfärbung [9] zu vergleichen, der in der Praxis gute Ergebnisse erzeugt. Die in Abbildung 3 dargestellte resultierende Schedule liegt bei 47μ s im Vergleich zu 148 μ s des ersten beschriebenen Ansatz. So benötigt beispielsweise die IRT-Übertragung 1 an Switch S1 7μ s für den Durchlauf des Daten-Frames zuzüglich 3μ s Verzögerung, die in dem grauen Block der ersten Zeile der Schedule dargestellt wird. Die Verzögerungszeiten verlängern die idealisierte Schedule, die 28μ s lang ist, um 68% bei der Anwendung des List-Schedulings. Der erste beschriebene Ansatz hingegen hat die Verzögerungszeiten pauschal auf jeden Zeit-Slot addiert und die Schedule dabei um 529% erhöht. Eine weitere interessante Eigenschaft des List-Schedulings besteht darin, dass es unabhängig von der Framelänge operieren kann. Ebenso können bei der Anwendung des List-Schedulings neben den Unicast-Übertragungen auch Multicast- und BroadcastÜbertragungen berücksichtigt werden. Dabei erhöhen sich lediglich die Anzahl der betroffenen Switches sowie die Anzahl der Konflikte im globalen Knotenkonfliktgraphen. Werden an den Rändern des Netzwerkes Hubs eingesetzt, so können diese jeweils wie ein einzelnes Gerät betrachtet werden.

5 Zusammenfassung und Ausblick Die erstellte formale Modellierung beinhaltet neben dem bereits vorgestellten Szenario des idealisierten Vollduplex-Netzes mit Unicast-Übertragungen zusätzlich idealisierte Halbduplex-Netze [10] sowie die Integration von Multicast- und Broadcast-Übertragungen auf eine gegebene Ethernet-Netzwerkinfrastruktur [11]. Ausserdem werden

Ein Framework für echtzeitfähige Ethernet-Netzwerke

9

Abb. 3: Optimierte Schedule mit Berücksichtigung der Verzögerungen der Switches

Wege zur Einbindung von asynchron auftretenden Übertragungen in das formale Modell diskutiert [11]. Siemens ProfiNet und EPL beispielsweise teilen ihre Schedules in jeweils einen isochronen und einen asynchronen Teil ein. Zusätzlich wurden im Rahmen der Forschung Modelle zur Einbindung variabler Frame-Größen ebenso diskutiert wie die Möglichkeit, nicht jeden Frame in jedem Produktionszyklus zu versenden. So müssen unter anderem unkritische Sensor-Daten nicht zwingend in jedem Kommunikationszyklus übertragen werden und können sich statt dessen abwechseln [11]. Mit diesem Framework wurde also ein grundlegendes formales Modell und eine technologie-unabhängige Vorgehensweise zur Berechnung von Zykluszeiten automatisierter Anlagen geschaffen. Die ersten realitätsnahen Erweiterungen binden Technologien wie Siemens ProfiNet und Ethernet PowerLink in die Modellierung ein. Als nächste Erweiterungen könnten Rundsende-Techniken von Frames, wie sie von Sercos III und EtherCAT verfolgt werden, in die Modellierung integriert werden. Ebenfalls sinnvoll ist es, das Modell auf reale automatisierte Anlagen anzuwenden, um Vergleiche zwischen einer theoretisch ermittelten und realen Zykluszeit anzustellen und um den praktischen Einsatz des Modells zu erproben. Dazu wurde bereits ein erster objektorientierter Prototyp geschaffen, der eine Simulation von Netzen, Protokollen und Schedule-Berechnungen mit verschiedenen Algorithmen zulässt [11]. Die Vollendung dieses Prototyps kann ein weiterer Bestandteil zukünftiger Forschung darstellen.

10

F. Dopatka

Literaturverzeichnis 1. Soucek S., Loy D.: Vertical Integration in Building Automation Systems. in: Proc. of the 5th IEEE Int. Conf. on Industrial Informatics 2007, Vol. 1, S. 81–86, 2007. 2. Schnell G.: Bussysteme in der Automatisierungs- und Prozesstechnik. Vieweg-Verlag, Braunschweig, Wiesbaden, 5. Auflage, 2003. 3. Moning A., Lanz R.: Datenkommunikation und Rechnernetze, 2006, FH Bern, Skript zur Vorlesung,     (01.07.07). 4. Nowak, U.: Graphentheoretische Modellierung eines automatisierungstechnischen Echtzeitnetzwerks und Algorithmenentwurf zum Kommunikations-Scheduling, Diplomarbeit der Universität Siegen, Fachbereich Mathematik,         (11.11.07). 5. Alon N.: A Simple Algorithm for Edge-Coloring Bipartite Multigraphs, in: Information Processing Letters 85, Nr. 6, 2003, S. 301-302, ISSN 0020-0190, ! "#$ #$#%$$&$'$#($)$&*$$++%',. 6. Scheitlin H., Zuber R.: Kommunizieren Sie pünktlich?, 2003,        - -   (03.07.07). 7. Popp M.: Das Profinet IO-Buch - Grundlagen und Tipps für Anwender, Hüthig-Verlag, Heidelberg, 2005, ISBN 3-7785-2966-8. 8. Turau V.: Algorithmische Graphentheorie, 2. Auflage, Addison-Wesley Verlag, München, 2004, ISBN 3-4862-0038-0. 9. Brélaz D.: New Methods to Color the Vertices of a Graph, in: Communications of the ACM 22, Nr. 4, 1979, S. 251-256, ISSN 0001-0782, ! "#$##+,.,($(+ .,(#$# (15.11.07). 10. Dopatka F., Wismüller R.: A Top-Down Approach for Realtime Industrial-Ethernet Networks using Edge-Coloring of Conflict-Multigraphs, in: IEEE International Symposium on Power Electronics, Electrical Drives, Automation and Motion (SPEEDAM), Taormina, Italien, 23.-26.05.2006, ISBN 1-4244-0193-3, S. 883-890. 11. Dopatka F.: Ein Framework für echtzeitfähige Ethernet-Netzwerke in der Automatisierungstechnik mit variabler Kompatibilität zu Standard-Ethernet, Dissertation der Universität Siegen, Fachbereich Elektrotechnik und Informatik, 2008,  !   ' "/

!&$$0.1$ (27.06.09).

UniLoG – ein System zur verteilten Lastgenerierung in Netzen Andrey Kolesnikov, Bernd E. Wolfinger und Martin Kulas Universität Hamburg, Department Informatik, Arbeitsgruppe TKRN, Vogt-Kölln-Str. 30, 22527 Hamburg       

Zusammenfassung. Mit wachsender Komplexität moderner Kommunikationsund Informationssysteme gewinnen entsprechende Leistungsanalysen und Verhaltensprognosen unter verschiedenen Lastszenarien für solche Systeme zunehmend an Bedeutung. Der Bedarf nach universellen Werkzeugen zur Modellierung und Generierung von Lasten steigt somit auch kontinuierlich. In diesem Beitrag werden zunächst Szenarien aus der Netzpraxis dargestellt, in denen verteilte Lastgenerierung besonders nützlich ist. Auf dieser Basis werden typische Anforderungen eines Experimentators an ein verteiltes Lastgenerierungssystem identifiziert. Anschließend wird der Aufbau eines konkreten Systems zur verteilten Lastgenerierung auf der Basis eines existierenden Lastgenerators U NI L O G und sein Einsatz zur Untersuchung der Übertragungsqualität von H.264-codierten Videoströmen unter Hintergrundlast in einem IEEE 802.11g WLAN im Rahmen einer Fallstudie präsentiert.

1 Einleitung Lastgeneratoren sind Softwaresysteme, welche in der Lage sind, anhand einer stochastischen Modellierung oder mittels Messwerten eines Experiments an einem existierenden Realsystem künstliche synthetische Verkehrslasten zu erzeugen, die (aus Sicht des Netzes) identisch sind mit den Lasten aus einer realen Anwendung. Lastgeneratoren (ein Überblick findet sich z.B. in [4]) sind bei Experimenten zur Leistungsanalyse von Netzen und Diensten ein sehr hilfreiches Mittel, da sie das Verhalten von realen Anwendungen oder Benutzern simulieren können, indem sie künstliche Verkehrslasten mit bestimmten Charakteristika gemäß einem Lastmodell erzeugen. Die Festlegung von Lastcharakteristika erfolgt durch die Wahl einer geeigneten Parametrisierung des zugrundeliegenden Lastmodells und ermöglicht damit einen sehr flexiblen Einsatz des Lastgenerators z.B. zur Herstellung von verschiedenen Hintergrundlastniveaus. Der Lastgenerator U NI L O G wurde bereits in [1] präsentiert. Der Einsatz von Benutzerverhaltensautomaten (BVA) zur Lastspezifikation [2, 3] erlaubt eine formale und einheitliche Vorgehensweise bei der Lastmodellierung mit U NI L O G sowohl für bereits existierende als auch für neue, sich in der Entwurfsphase befindliche (Dienst)Schnittstellen. Mithilfe von schnittstellenspezifischen Adaptern können entsprechende reale Paketströme an den Schnittstellen zu UDP, TCP, HTTP und seit kurzem zu IP [4] generiert werden.

12

A. Kolesnikov, B.E. Wolfinger, M. Kulas

Ein verteiltes Lastgenerierungssystem, welches aus mehreren lastgenerierenden Komponenten (Lastgeneratoren) besteht, kann die Flexibilität bei der Herstellung von verschiedenen Lastszenarien noch weiter erhöhen. Die meisten bekannten Lastgeneratoren sind als Software realisiert und können auf einem handelsüblichen PC ausgeführt werden. Die Realisierung eines Lastgenerators in Software kann u.U. nicht den erforderlichen Flexibilitäts- und Leistungsgrad erbringen, um Experimente in größeren Providernetzen oder im Internet durchführen zu können. So wird es schwierig sein, mit einem einzigen zentralisierten Lastgenerator Testverkehr für einen Gigabit-Router zu erzeugen, um z.B. sein Verhalten im Hochlastbereich zu untersuchen. Bei einer verteilten Lösung kann jeder Lastgenerator ein eigenes Lastmodell ausführen, so dass verschiedene Verkehrsströme parallel erzeugt und in das Netz eingespeist werden können. Auf diese Weise bietet die verteilte Lösung erhebliche Vorteile für die Lastgenerierung insbesondere in folgenden Situationen: – Erzeugung von Testverkehr mit sehr hohen Datenraten (im Bereich mehrerer Gbit/s) in einem Subnetz, einem Netzknoten bzw. auf einer bestimmten Übertragungsstrecke. – Erzeugung von verschiedenen Verkehrsmixen (durch Überlagerung bzw. Superposition verschiedener Arten von Verkehr) in irregulär vermaschten Netzen (z.B. zur Leistungsanalyse von Routingalgorithmen oder Lastausgleichstechniken, vgl. [5]). – Durchführung von Experimenten in gekoppelten Netzen (z.B. Ethernet mit WLAN, ATM mit IP, etc.) und Analyse von ggf. geographisch weit verteilten Netzteilen durch die zentrale Steuerung der Komponenten des verteilten Lastgenerators. – Unterstützung beim Entwurf von Systemen zur Erkennung von Verkehrsanomalien [6] und DDoS-Angriffen [7]. Das Ziel dieser Arbeit ist der Aufbau eines Systems zur verteilten Lastgenerierung auf der Basis des zentralisierten Lastgenerators U NI L O G (vgl. [4] zum aktuellen Stand der Entwicklung). Im folgenden Abschnitt 2 werden zunächst die wichtigsten (“zentralen“) Anforderungen an ein verteiltes Lastgenerierungssystem identifiziert und untersucht, inwieweit die existierenden Lastgeneratoren diese Anforderungen erfüllen. In Abschnitt 3 wird die Systemarchitektur eines verteilten Lastgenerierungssystems auf U NI L O G-Basis skizziert und in Abschnitt 4 werden die Schlüsselaspekte der Realisierung präsentiert. Ein erster Einsatz des entstandenen verteilten Lastgenerierungssystems U NI L O G-Distributed zur Verkehrsgenerierung in einem IEEE 802.11g-WLAN wird in Abschnitt 5 präsentiert und rundet diesen Beitrag ab.

2 Ausgangssituation und Randbedingungen Die Ausgangsbasis für diese Arbeit stellt ein Software-Lastgenerator U NI L O G dar, mit dem sich elementare Lastquellen (z.B. Video- oder Audioströme) in einem Netz aufwandsarm modellieren und entsprechende künstliche Lasten/Verkehre mittels schnittstellenspezifischer Lastadapter generieren lassen. Zu einer ausführlichen Darstellung der Testergebnisse bezüglich der Leistungsfähigkeit und der Präzision von U NI L O G für verschiedene Paketlängen siehe [1] (für den TCP- und den UDP-Adapter) bzw. [4] (für den IP-Adapter).

UniLoG – ein System zur verteilten Lastgenerierung in Netzen

13

Bei der Generierung von UDP- und TCP-Paketströmen mithilfe des UDP- und TCPAdapters muss der Experimentator berücksichtigen, dass die Quell-IP-Adresse der generierten Pakete mit der IP-Adresse des jeweils verwendeten Adapters übereinstimmen wird. Dies macht eine Installation des UDP- bzw. des TCP-Adapters in allen Netzknoten erforderlich, die an dem geplanten Experiment beteiligt sind und entsprechende UDP- bzw. TCP-Paketströme generieren sollen. Durch die freie Wahl der Ziel-IPAdresse unterstützen der UDP- und TCP-Adapter Generierung von Verkehr mit einer “1:n-Verkehrsmatrix“ (1:n für “von einem Sender zu n Empfängern“) auf der IP-Ebene und durch die Verwendung von mehreren verschiedenen Quellports im Adapter lassen sich auch Paketströme mit einer “m:n-Verkehrsmatrix“ auf der Transportebene generieren. Der IP-Adapter ermöglicht dem Experimentator hingegen, auch solche IP-Pakete ins Netz zu injizieren, deren Quelladresse von der IP-Adresse des Lastgenerators abweicht. Auf diese Weise können mehrere IP-Paketströme mit ggf. unterschiedlichen Quell-IP-Adressen mithilfe eines einzigen Lastgenerators in das untersuchte Netz injiziert werden. So unterstützt der IP-Adapter eine Generierung von Verkehr mit einer “m:n-Verkehrsmatrix“ bereits auf der IP-Ebene und muss nicht zwingend in allen lastgenerierenden Knoten des Experimentnetzes installiert werden. Falls im Rahmen eines Experiments IP-Verkehrslasten auf einer bestimmten Übertragungsstrecke bzw. in bestimmten Netzknoten erzeugt werden sollen, muss der Experimentator ggf. doch mehrere Lastgeneratoren (mit jeweils einem IP-Adapter) installieren, womit auch eine Notwendigkeit für die Koordination und Steuerung der installierten Lastgeneratoren entsteht. 2.1 Zentrale Anforderungen Anhand der bisherigen Überlegungen lassen sich folgende zentrale Anforderungen an ein System zur verteilten Lastgenerierung identifizieren: Fernsteuerbarkeit: Ein Benutzer von U NI L O G (im weiteren der Experimentator) soll Lastgenerierungsvorgänge von einer zentralen Station ansteuern und deren Fortschritt überwachen können. Insbesondere muss es möglich sein, ausgewählte Lastgeneratoren ASAP (d.h. as soon as possible) oder zu einem bestimmten physikalischen Zeitpunkt (z.B. um 12:oo Uhr, MEZ) starten zu können. Alle für die Lastgenerierung benötigten Komponenten (Lastgeneratoren, erforderliche Adapter, auszuführende Lastmodelle sowie ggf. benötigte Traces mit Parameterwerten) sollen vor dem Experiment von einer zentralen Stelle aus auf die beteiligten Netzknoten verteilt werden können. Synchronisation der physikalischen Uhren: Um einen Start der beteiligten Lastgeneratoren zu einem (an der zentralen Station) festgelegten physikalischen Zeitpunkt zu ermöglichen, sollen die physikalischen Uhren der Lastgeneratoren zumindest mit der physikalischen Uhr in der zentralen Station synchronisiert sein. Je nach Experimentart kann die Uhr in der zentralen Station noch mit einer externen physikalischen Uhr synchronisiert werden. Globale Uhrensynchronisation zwischen Netzknoten ist ein recht komplexes, z.B. mittels Network Time Protocol, NTP (vgl. [10]), lösbares Problem.

14

A. Kolesnikov, B.E. Wolfinger, M. Kulas

Skalierbarkeit: Skalierbarkeit eines Lastgenerierungssystems bedeutet, dass zusätzliche modellierte Lastquellen ohne großen Aufwand hinzugefügt werden können. Dies ist eine sehr wichtige Anforderung für die Netzpraxis, da eine Superposition (Überlagerung) mehrerer Lastquellen und damit die Generierung von zusammengesetzten (aggregierten) Verkehrsströmen (Verkehrsmixen) im Netz ermöglicht wird. Bisher existieren in U NI L O G folgende Möglichkeiten zur Modellierung von aggregierten Verkehrsströmen: – Analytische Modellierung des aggregierten Verkehrsstroms und Abbildung als BVA (z.B. durch Bestimmung von geeigneten Verteilungsfunktionen und parametern im Rahmen spezieller Laststudien, vgl. z.B. [11]). – Erzeugung von Traces zur Beschreibung der Einzelströme und anschließendes “Mischen“ dieser Traces zu einem Trace für die zu generierende Gesamtlast. – Verwendung von mehreren Generator-Komponenten, von denen jede ein eigenes BVA-Modell ausführt (vgl. [1]). Die Verwendung von mehreren geographisch verteilten Lastgeneratoren würde die maximale Flexibilität bei der Generierung von verschiedenen Verkehrsmixen liefern. Sicherheitsaspekte: Es sollen Maßnahmen zum Schutz des Lastgenerierungssystems vor Missbrauch realisiert werden, insbesondere muss sich der Experimentator bzw. die zentrale Station gegenüber den Lastgeneratoren authentisieren. Darüber hinaus muss die Vertraulichkeit der Kommunikation zwischen der zentralen Station und den Lastgeneratoren (z.B. durch TLS-Verschlüsselung) gewährleistet werden. 2.2 Einige bereits exisitierende Lösungen Erste Vorarbeiten in Richtung verteilter Lastgenerierung wurden an der Arbeitsgruppe TKRN in [3] und [9] geleistet. Der in [9] entwickelte erste Prototyp eines verteilten Lastgenerierungssystems verwendete Java Remote Method Invocation (RMI), um U NI L O G-Adapter mit verschiedenen im Voraus generierten Traces von Auftragssequenzen entfernt aufzurufen. Die Kommunikation mit den Adaptern erfolgte unverschlüsselt und die aufrufende Instanz authentisierte sich gegenüber den Adaptern mittels eines im Klartext übertragenen Passworts. Eine Verteilung der Lastmodellkomponenten und die Ausführung der BVAs in den einzelnen Lastgeneratorknoten in Echtzeit war nicht vorgesehen. Die gewählte Middleware RMI setzte eine entsprechende Installation der RMI-Registry und ggf. eine geeignete Konfiguration der Firewall voraus.

3 Systemarchitektur zur verteilten Lastgenerierung Das erweiterte System zur verteilten Lastgenerierung in dieser Arbeit besteht aus folgenden funktionalen Hauptkomponenten: Lastgeneratoren sind Software-Komponenten, die spezifizierte Lasten erzeugen. Dazu gehören die bisherigen U NI L O G-Komponenten GAR (Generator abstrakter Aufträge, zuständig für die Ausführung von parametrisierten BVA-Modellen) sowie Adapter, die für die Generierung von realen Verkehrslasten an verschiedenen Netzschnittstellen (z.B. UDP oder IP) verantwortlich sind, vgl. Abb. 1.

UniLoG – ein System zur verteilten Lastgenerierung in Netzen

15

(Last-)Agenten (vgl. “Agenten“ im Simple Network Management Protocol, SNMP, RFC 3410-3418) sind lokal in den lastgenerierenden Knoten installiert und sind in der Lage, den Lastgenerierungsprozess in den Lastgeneratoren zu überwachen und zu steuern. Sie bieten damit einen Lastgenerierungsdienst für authorisierte Experimentatoren an. Die (Last-)Agenten sowie die Lastgeneratoren gehören zusammen zur Lastgenerierungssoftware, die in den Knoten benötigt wird, um ein Lastexperiment durchzuführen. Zentrale Managementstation (vgl. “Manager“ bei SNMP) übernimmt die Fernsteuerung, Fernkonfiguration und Überwachung von Lastgeneratoren, die in einem Netz installiert sind, und kann mit den Lastagenten über ein Netzwerk kommunizieren.

16

A. Kolesnikov, B.E. Wolfinger, M. Kulas

Der Experimentator kann von der zentralen Management-Station den Lastgenerierungsdienst der assoziierten Lastagenten durch Übergabe von Steuerkommandos benutzen. Die unterstützten Steuerkommandos sind in Tab. 1 zusammengefasst. Für den Transport werden die Steuerkommandos als  bzw. -Nachrichten verpackt. Kommando                   

Beschreibung Hochladen eines PBVA-Lastmodells zum Lastagenten Hochladen eines (Parameter-)Traces zum Lastagenten Unverzüglicher Start der Lastgenerierung Start der Lastgenerierung zum vorgegebenen Zeitpunkt (Unverzügliches) Beenden der Lastgenerierung Abfragen des Lastgeneratorstatus ( ,   ) Holen eines Lastgenerierungsberichtes

Tabelle 1: Steuerkommandos an den Lastagenten Ein Lastagent kann den entsprechenden Lastgenerator entweder unverzüglich (bei Übergabe des Kommandos 

   ) oder zu einem bestimmten Zeitpunkt (z.B. 

    ,  ) starten, der von der Management-Station aus vorgegeben werden kann. Die Dauer der Lastgenerierung entnimmt der Lastgenerator dem PBVA-Modell, welches als Argument in den Startkommandos übergeben wird. Damit die Lastgeneratoren den Initialisierungszustand des BVA zeitgleich verlassen können, wird das Zeitsignal in den lastgenerierenden Stationen mithilfe des NTP-Clients mit dem Zeitsignal in der Management-Station synchronisiert. Das Zeitsignal in der Management-Station kann zusätzlich mit einem externen NTP-Server synchronisiert werden, falls die Übereinstimmung der Zeit im verteilten Lastgenerierungssystem mit der realen Uhrzeit gefordert wird. Gemäß RFC 1305 unterstützt NTP eine Zeitgenauigkeit bis in den Nanosekundenbereich hinein. Die tatsächlich erreichbare Genauigkeit hängt jedoch in großem Maße von den verwendeten Betriebssystemen und der Qualität der Netzwerkverbindungen ab. So kann mithilfe von NTP eine Genauigkeit der Uhrensynchronisation von 1-10 ms im Internet und von bis zu 200 μ s in lokalen Netzen erreicht werden (vgl. [10]), die für den verteilten Lastgenerator ausreichend ist. Mit !   " kann ermittelt werden, ob der betreffende Lastgenerator noch aktiv oder bereits terminiert ist. Die für den Experimentator wichtigen Lastgenerierungsstatistiken (wie z.B. die Anzahl generierter Pakete, die Lastgenerierungsdauer, die entsprechende Paket- und Datenrate, etc.) können mithilfe von ! #$ abgefragt werden.

4 Stand der Realisierung Für die Realisierung des in dieser Arbeit präsentierten verteilten Lastgenerierungssystems U NI L O G-Distributed wurden bereits folgende Schritte ausgeführt: Lastgeneratoren: die bisherigen U NI L O G-Lastgenerierungskomponenten wurden angepasst, damit der Lastgenerierungsprozess zu einem vorgegebenen physikalischen Zeitpunkt gestartet werden kann.

UniLoG – ein System zur verteilten Lastgenerierung in Netzen

17

Lastagenten: wurden mit Skriptsprache  realisiert. Für die Verarbeitung von Steuerkommandos im  -Format wurde das Open-Source-Rahmenwerk   verwendet. Authentifizierung und Verschlüsselung: die Authentifizierung der Management-Station und der Lastagenten erfolgt mithilfe der X.509-Zertifikate. Dafür wurde eine eigene Zertifizierungsinstanz (CA) mittels des  -Softwarepakets aufgebaut, Schlüsselpaare für die Management-Station und die Lastagenten erzeugt und von der CA signiert. Nach der erfolgreichen Authentifizierung findet die Kommunikation zwischen der Management-Station und den Lastagenten über eine verschlüsselte TLS-Verbindung statt. Management-Station: wurde als -Modul realisert, mit dem Steuerkommandos als  -Nachrichten an die Lastagenten übergeben werden können. Eine spezielle GUI für die Management-Station kann zu einem späteren Zeitpunkt realisiert werden.

5 Fallstudie: Lastgenerierung mit einem Lastagenten in einem WLAN Eine Fallstudie zur Untersuchung der Übertragungsqualität eines Films (Streaming Media) unter verschiedenen Hintergrundlasten in einem IEEE-802.11g-WLAN rundet diesen Beitrag ab. Dabei wird der Einsatz eines Lastagenten zur Herstellung verschiedenartiger Hintergrundlasten an der IP-Schnittstelle präsentiert und deren Einfluss auf die Übertragungsqualität des Films untersucht. Diese Fallstudie stellt eine typische Hotspotsituation nach, in welcher ein Benutzer über ein WLAN auf einen Video-on-Demand-Dienst (VoD) im Internet durch RTP/RTSP (RFC3550, RFC2326) zugreift, um die Audio- und Videoströme eines qualitativ hochwertigen Films zu empfangen. Neben diesem Filmempfänger stellt ein Lastagent das Verhalten weiterer WLAN-Stationen nach, indem er eine IP-Hintergrundlast in der Funkzelle erzeugt. Dabei stellen sich u.a. folgende Fragen: (1) Ab welcher Hintergrundlast entsteht eine signifikante Verschlechterung der Filmübertragungsqualität? (2) Welche Rolle spielt die Art der Hintergrundlast? (3) Bei welcher Hintergrundlast wird der Streamingdienst “unbrauchbar“? Das Fallstudiennetz besteht aus einem Fast-Ethernet-Segment mit einem VoDServer und einer Lastsenke und aus einem IEEE-802.11g-WLAN-Segment mit einem VoD-Client und einem Lastagenten (s. Abb. 2). Der Lastagent erzeugt eine synthetische IP-basierte Hintergrundlast mittels eines IP-Lastgenerators. Die WLAN-Stationen sind ca. zwei Meter voneinander entfernt aufgestellt, haben direkte Sichtverbindung und verwenden keinen RTS/CTS-Mechanismus. Der VoD-Client empfängt den Film vom VoD-Server über das WLAN, während der Lastgenerator IP-Pakete über das gleiche WLAN zur Lastsenke schickt. Dadurch konkurrieren der VoD-Client und der Lastgenerator um den Zugriff auf das Funkmedium. Die Lastsenke versendet keine Nachrichten während der Fallstudienexperimente. Aus der Umgebung der Funkzelle empfängt man Beacon-Rahmen von acht fremden Access-Points, welche mit den Signalen im Fallstudien-WLAN interferieren können.

18

A. Kolesnikov, B.E. Wolfinger, M. Kulas

Abb. 2: Aufbau des Fallstudiennetzes

Als Filmmaterial verwendet diese Fallstudie den freien Animationskurzfilm Big Buck Bunny des Peach-Open-Movie-Projektes. In der Fallstudie überträgt der VoDServer diesen 10 Minuten langen Film in der High-Definition-Auflösung von 1280x720 Pixel mit einem H.264/AVC-Videostrom und mit einem MPEG-4 codierten Audiostrom mittels der VoD-Software VLC. Die Fallstudie verwendet solche Hintergrundlasten, welche eine Engpassanalyse des Netzes ermöglichen und das Netz in den Hochlastbereich bringen. Dazu werden Lastmodelle verwendet, welche Verkehr mit sowohl konstantem (CBR) als auch variablem (VBR) Durchsatz auf IP-Ebene generieren, damit eine mittlere IP-Hintergrundlast von 1, 2, 4, 8, 16, 20, 24, oder 32 MBit/s entsteht. In den Versuchen mit CBR-Verkehr haben die IP-Pakete eine konstante Frachtlänge von entweder 50 oder 1480 Byte. Die VBR-Versuche verwenden ebenfalls die konstanten Frachtlängen von 50 oder 1480 Byte, doch sind die Zwischenankunftszeiten exponentiell verteilt. In einem WLAN nach IEEE-802.11g-Standard ergibt sich bei 50 Byte kleinen IP-Frachtlängen ein maximaler IP-Durchsatz von ungefähr 4,9 MBit/s, sodass diese Fallstudie den IP-Durchsatz der Hintergrundlast auf 4 MBit/s beschränkt. Als Übertragungsqualitätsmaße betrachtet die Fallstudie den Jitter (extrahiert aus Receiver-Reports der RTP-Übertragung) und den mittleren Durchsatz an der IP-Schnittstelle auf Seiten des VoD-Clients (ermittelt aus den aufgezeichneten RTP- und IPPaketen). Durch Erhöhen der Hintergrundlast verschlechterte sich wie erwartet die Qualität der übertragenen Video- und Audioströme. Unzumutbar für Betrachter wurde die Filmübertragung, wenn die Hintergrundlast in den Hochlastbereich kam. Dort “verhungerte“ die Video-on-Demand-Abspielsoftware, d. h. sie erhielt zu wenig Audio- und Videodaten, um Bilder und Töne wiederzugeben. Diesen Einbruch in der Qualität sieht man in den Werten zu den Übertragungsqualitätsmaßen in Abb. 3; der mittlere IP-Durchsatz fiel z.B. bei einer CBR-Last, welche 32 MBit/s auf IP-Ebene mit 1480 Byte langen IP-Frachten erzeugte, auf ungefähr 1,5 MBit/s (ohne Last: ca. 5,7 MBit/s) während der mittlere Jitter auf ca. 34 ms anstieg (von etwa 3,4 ms bei fehlender Last).

UniLoG – ein System zur verteilten Lastgenerierung in Netzen 6

50

5.5

CBR-Last 50 Byte

5

40

Jitter [ms]

4 3.5 VBR-Last 50 Byte

20

3

VBR-Last 1480 Byte

2.5

IPDurchsatz [MBit/s]

VBRLast 1480 Byte 4.5

CBR-Last 1480 Byte 30

19

VBRLast 50 Byte CBRLast 1480 Byte

2

10

1.5 0

CBRLast 50 Byte

1 0 1 2

4

8

16 20 24 mittlere IP-Hintergrundlast [MBit/s]

(a)

32

0 1 2

4

8

16 20 24 mittlere IPHintergrundlast [MBit/s]

32

(b)

Abb. 3: Verlauf der Jitterwerte und des IP-Durchsatzes

Die Fallstudie stellt fest, dass Lasten mit kleinen Paketlängen von z. B. 50 Byte bereits bei niedrigem mittlerem IP-Durchsatz (4 MBit/s) ein 802.11g-WLAN in den Hochlastbereich treiben. Dies liegt daran, dass die Datensicherungs- und die Bitübertragungsschicht der WLAN-Stationen mehrere Verfahren zum zuverlässigen Datenübertragen verwenden, welche beim Datenübermitteln zu einem Mehraufwand führen und somit den IP-Durchsatz bei kleinen Paketlängen stark einschränken. Des Weiteren liest man aus den Versuchsergebnissen heraus, dass sich die Qualitätsmaße wenig unterscheiden, wenn die CBR- und VBR-Versuche die gleichen Frachtlängen und den gleichen mittleren IP-Durchsatz verwenden. Eine bedeutendere Rolle als die Wahl der Zwischenankunftszeitenverteilung spielt somit in der Fallstudie die Paketlänge, denn sie bestimmt, wie lange eine WLAN-Station das Übertragungsmedium belegt.

6 Resümee und Ausblick In diesem Beitrag wurden zunächst die Notwendigkeit und die Vorteile einer (geographisch) verteilten Lastgenerierung aufgezeigt und die zentralen Anforderungen an ein System zur verteilten Generierung von Lasten bzw. daraus resultierenden Verkehrsströmen identifiziert. Anschließend wurden ausgewählte Realisierungsaspekte des verteilten Lastgenerators U NI L O G-Distributed skizziert und das bereits existierende System wurde im Rahmen einer relativ umfangreichen Fallstudie erfolgreich eingesetzt. Neben ihren konkreten Resultaten zur Leistungs- und QoS-Prognose für ein realistisches WLAN-Szenario demonstriert die Fallstudie potentielle Einsatzgebiete verteilter Lastgeneratoren. Möglichkeiten für weitere Aktivitäten sehen die Autoren in der Entwicklung von weiteren Adaptern für U NI L O G, in der Erweiterung der bisherigen GUI (insbesondere auch im Hinblick auf eine komfortable Unterstützung von wenig erfahrenen Experimentatoren in den Bereichen formale Lastbeschreibung und Lastmodellierung) sowie in der Verfeinerung des U NI L O G-Distributed-Systems und dessen Nutzung im Rahmen weiterer Fallstudien.

20

A. Kolesnikov, B.E. Wolfinger, M. Kulas

Literaturverzeichnis 1. A. Kolesnikov, “Konzeption und Entwicklung eines echtzeitfähigen Lastgenerators für Multimedia-Verkehrsströme in IP-basierten Rechnernetzen“, GI/GMA-Fachtagung Echtzeitsysteme, Boppard am Rhein, 2008, pp. 91-100. 2. B. E. Wolfinger, “Characterization of Mixed Traffic Load in Service-Integrated Networks“, Systems Science Journal, vol. 25, no. 2, pp. 65-86, 1999. 3. J. Cong, “Load Specification and Load Generation for Multimedia Traffic Load in Computer Networks“, Dissertation, Shaker, Aachen, 2006. 4. A. Kolesnikov, M. Kulas: Lastgenerierung an IP-Schnittstellen mit dem UniLoG.IP-Adapter, 5. GI/ITG-Workshop MMBnet, Hamburg, 2009, pp. 24-35. 5. T. Leighton, “Improving Performance on the Internet“, ACM Queue, vol. 6, no. 6, pp. 20-29, Oct. 2008. 6. Y. Xie und S. Z. Yu, “A Large-Scale Hidden Semi-Markov Model for Anomaly Detection on User Browsing Behaviors“, IEEE Transactions on Networking, vol. 17, no. 1, pp. 54-65, Feb. 2009. 7. Y. Xie und S. Z. Yu, “Monitoring the Application-Layer DDoS Attacks for Popular Websites“, IEEE Transactions on Networking, vol. 17, no. 1, pp. 15-25, Feb. 2009. 8. SLAMD Distributed Load Generation Engine,    . 9. M. Schwengel, “Verteilte Lastgenerierung, Architekturen, Realisierungen und Fallstudien“, VDM Verlag Dr. Müller, Saarbrücken, 2007. 10. D. L. Mills, “Computer Network Time Synchronization: The Network Time Protocol“, CRC Taylor & Francis, Boca Raton, 2006. 11. H. Hassan, J. M. Garcia und C. Bockstal, “Aggregate Traffic Models for VoIP Applications“, Proc. of ICDT’06, Cap Esterel, 2006, pp. 70-75.

Planning of Time Triggered Communication Schedules Olaf Graeser and Oliver Niggemann inIT – Institut Industrial IT Ostwestfalen–Lippe University of Applied Sciences 32657 Lemgo, Germany       

Abstract. Fieldbus systems like Profinet IRT use network technologies which are compatible with common office networks like Ethernet. In order to enable real–time communication, bandwidth reservation is used in these networks. The length of the reserved bandwidth depends on preplanned message schedules. It is an important task to minimise the reserved bandwith to allow additional non real– time communication in these networks and to get short communication cycles. In this paper a heuristic scheduling algorithm is presented. This paper is based on ongoing work and presents first results.

1 Introduction Fieldbus systems are used in industrial automation to implement decentralised control systems. Fieldbusses are communication networks specialised for automation purposes. Especially factory automation has hard real–time requirements and therefore needs a deterministic communication system. Management processes of an automated plant are often connected to the office network of a company. These management processes frequently require a direct and transparent access to the fieldbus system. For this reason fieldbus systems like Profinet [1], EtherCAT [2] and SercosIII [3] are using networks compatible to the Ethernet standard. The Ethernet standard was not developed for the requirements of industrial automation, hence there are difficulties in the utilisation of this technology [4,5]. To overcome these difficulties the mentioned fieldbus systems replace or modify the Media Access Control of the Data Link Layer of Ethernet. The objectives of these modifications are to enable the communication system to comply with hard real–time requirements [6, 7]. The application example Profinet IRT (Isochronous Real–Time) is a modified switched Ethernet which complies with the real–time requirements of industrial automation and which is compatible with Ethernet. This is achieved by using two communication phases: One phase for real–time communication and another phase for non real–time communication (fig. 1). To guarantee deterministic transmission times for the real–time phase, Profinet IRT uses time slots with Time–Division–Multiple–Access (TDMA). By minimising the length of the real–time communication phase more bandwidth becomes available for the non real–time communication phase or for additional real– time communication. This minimisation task requires a preplanning of communication routes through the network and of the communication schedules of the cyclic real–time messages. This paper focuses on the scheduling problem.

22

O. Graeser, O. Niggemann

Fig. 1: Communication phases in Profinet IRT

The schedule planning is comparable to the well known Job–Shop Problem (JSP) [8]. In the JSP n tasks (jobs) with m subtasks have to be handled. The sequence of the subtasks is compulsory and each subtask has to be handled on a specific machine. The machine can handle only one task at time and the tasks are not preemtive. Comparatively the ports of switches can be considered as machines which transport messages (jobs/tasks) along multiple switches (subtasks) to theirs destination. The JSP belongs to the NP-hard problems [9, 10]. This means, that the effort to find the optimum schedule in a complex network can be unacceptably large. In this work a heuristic search algorithm is considered to explore the search space as purposeful as possible to keep the search complexity low.

2 Related Work The work of Dopatka [6] deals with the topic of planning communication schedules for Profinet IRT. This approach starts with a simplified Profinet network with uniform frame–lengths, unicast and half–duplex transmissions. For the schedule planning, the routes of IRT–transmissions over the switches are considered. There is a conflict, whenever two or more IRT–transmissions need the same port of a switch. These conflicts can be presented in node or edge conflict graphs for each switch. Heuristic colouring algorithms for the conflict graphs are used to create local schedules for the switches. The local schedules can be synchronised to provide a schedule for the whole network. In the further process of his work Dopatka changes to full-duplex transmissions and adds broadcast and multicast transmissions, variable frame sizes and different bridging delays of the switches. This leads to the idea to use a list–scheduling algorithm with graph–colouring for optimisation by pre–sorting. Since the planning problem is comparable to the JSP, approaches for the JSP are also related to this work. Surveys are provided by [11] and [12]. The approaches can be divided into the classes approximation and optimisation. The class of approximation approaches contains for example artificial intelligence with neural networks, expert systems and solutions for constraint satisfaction problems, local search heuristics like genetic algorithms or tabu search and constructive methods like the shifting bottleneck heuristic. The class of optimisation approaches includes for example the branch and bound algorithm or linear programming [12].

Planning of Time Triggered Communication Schedules

23

3 Formal Representation The Profinet IRT network can be seen as a directed and weighted graph G = (V, E, w), where V is the set of switches used as vertices and E is the set of network cables connecting the ports of the switches as edges.

G = (V, E, w)

(1)

V = {s1 , s2 , s3 , ..., s|V | }

(2)

E = {e1 , e2 , e3 , ..., e|E| }

(3)

w:E →N

(4)

The function w provides the weight of a given edge. The weight of an edge represents the transmission delay between two switches. This delay is the sum of the bridging and the sending delay (tx–delay) of the sending switch, the delay over the network cable and the receiving–delay (rx–delay) of the receiving switch. When two different types of switches with different delay values are connected by a network cable, the delays in the different communication directions can be different. For this reason, the network graph has two directed and weighted edges for each switch connection (fig. 2).

Fig. 2: Small network example with some delays

Messages in Profinet IRT networks can be unicast or multicast messages. In this work only unicast messages are considered. Messages are send from a source to a sink (destination). Let M be the set of all messages in a network. Since there are multiple routes possible to connect two switches in a meshed network, the set Pi contains all possible (different) routes pi for one message mi . Definition 1 (Path) Let G = (V, E, w) be a graph, v1 , v2 ∈ V vertices in G and mi ∈ M a message from v1 to v2 . A path pi is a sequence of edges between the vertices v1 and v2 given by e = (e1 , ..., en ) ∈ E n with e1 = (v1 , v ) and en = (v , v2 ), v , v ∈ V ei−1 = (v , vk ) and ei = (vk , v ), v , v , vk ∈ V, i = 2...n

24

O. Graeser, O. Niggemann

Definition 2 (Schedule ) The transmission of a message mi ∈ M consists of a path pi and a function δi . The function δi maps an edge e ∈ pi to a time interval in which the edge e is used for the transmission of mi . Within this time interval the edge cannot be used for other transmissions. A valid schedule S for a network is a set of such transmissions. In case of one of the edges being used by more than one message transmission, the resulting time intervals must not overlap (5) – (7).

S = {< mi , pi , δi >| k = 1, ..., |M|} with δi : pi → R2 ∀ < mi , pi , δi >, < m j , p j , δ j > ∈ S :

(5) (6)

∀e ∈ E, e ∈ pi ∧ e ∈ p j ∧ i = j : δi (e) ∩ δ j (e) = 0/

(7)

Definition 3 (Quality of a Schedule) A schedule can be evaluated as the sum of the individual transmission times needed for the messages from theirs sources to theirs sinks.

μ (S) =

∑

(tend − tstart )

(8)

<mi ,pi ,δi >∈S

and (tstart ,t  ) = δi (e1 )

(9)

and (t  ,tend ) = δi (en ) and pi = (e1 , ..., en)

(10) (11)

Definition 4 (Optimal Schedule) A schedule S is optimal, when μ (S) is minimal. For the optimal Schedule Sopt and any other Schedule S relation (12) is valid. ∀ Schedule S : μ (Sopt ) ≤ μ (S)

(12)

Definition 5 (Perfect Network) A perfect network is an assumed network without any (hardware generated) delays and without any collisions of messages. The time for sending a message depends only on the message length and the bandwidth of the network. The schedule for this network is S per f ect and since there are no collisions or delays, all messages can be send immediately. Definition 6 (Relative Quality of a Schedule) The quality of a schedule S is given by μ (S). Let S per f ect be the perfect schedule for the assumed perfect network and Sreal a schedule for the real network. The relative quality of the Schedule S is then:

ν (Sreal ) =

μ (S per f ect ) μ (Sreal )

(13)

The relative quality of a schedule S is in a range of 0 < ν (S) < 1 with ν (S) = 1 for a perfect schedule in a perfect network.

Planning of Time Triggered Communication Schedules

25

4 The Algorithms Two search problems have to be solved, routing and scheduling. Even if it is not viable to search the complete search space for the optimal schedule, investigations on a complete search reveals the complexity of the scheduling problem. Therefore the first approach is an algorithm that creates all possible and valid schedules for a given set of messages in a network and selects the best schedule out of all schedules (section 4.1). The second approach is a greedy best–first search heuristic (section 4.2) which constructs a solution. The well known Dijkstra algorithm delivers the shortest route for a message and the modification to receive additional short routes is briefly described in section 4.3.

4.1 Complete Search To receive all possible valid schedules, it is necessary to look at all permutations of message sequences. Furthermore for each message in these message sequences, every possible route must be investigated. Having these two loops, the schedule for each single message must be calculated. This is done in a function called portOccupation. The function portOccupation examines for a message with a given route all edges used by this route (every port of each switch has its own edge, therefore an edge can be seen as a port). If one or more of the edges is already in use by another (earlier) message of the sequence, then the edge with the longest time of occupation is selected. This occupation–time is needed to calculate the start time offset for the message given to the portOccupation function. To calculate the start time for the message, all weights from the starting edge of this message to the longest occupied edge (exclusive) are aggregated. This sum is then subtracted from the occupation–time. The result is the start time for this message. Fig. 2 presents a small network consisting of seven nodes. For example, there shall be two messages (m1 , m2 ). Message m1 goes from node 5 to node 6 and message m2 goes from node 1 to node 4. Both messages use the edge between node 2 and node 3. For simplification this edge is addressed as edge e2,3 . Because m1 is scheduled first in this example, the edge e2,3 is occupied by m1 until 21 time units (tu). This is the occupation–time. Message m2 is scheduled second, the weights of the edges from the start to the occupied edge are aggregated and then subtracted from the occupation– time. In this example this is only edge e1,2 and results in 10tu. Hence, the start time for message m2 is 21tu − 10tu = 11tu. As result, the complete search algorithm delivers for each schedule a port–/edge– occupation map. This map holds for each edge an occupation time. The search algorithm has currently three different decision functions to find the best schedule of all schedules. The first function returns the schedule, in which the edge occupation of the most occupied edge is shorter than in all other schedules. The second functions returns the schedule, in which the average edge occupation is shorter than in all other schedules, and the third function returns the schedule, in which the occupation time of the most often used edge is shorter than in all other schedules.

26

O. Graeser, O. Niggemann

The number of different message sequences to be considered is given by m! for m messages. In worst case, the network is fully meshed. In this case, for each unii cast message exist 1 + ∑n−1 i=2 (∏ j=2 (n − j)) routes in a network with n > 1 nodes. For completeness, all these routes have to be considered for scheduling. 4.2 Greedy Best–First Search Heuristic The best–first search algorithm is a well known search algorithm which uses heuristics to move through the search space. Here we use a greedy variant of the best–first search algorithm as described in [8], where the search space is reduced to a tree. The algorithm selects a tree node for expansion based on an evaluation function f . Evaluated is the distance to the goal network node. A second function used in the greedy best–first search heuristic is the heuristic function h, which estimates the costs of a path from a specific network node to a goal network node. In this work, the tree nodes of the search tree are the messages. The root tree node is empty and has as many child nodes as message–route combinations exist. For example figure 3 has 3 messages, m1 , m2 and m3 . For message m1 and m2 exists only 1 route (r1 ), for message m2 exist 2 routes (r1 and r2 ). Hence there are 4 message–route combinations as child nodes of the root node.

Fig. 3: Example of a tree used for the greedy best–first search algorithm

The evaluation function f (m, r) delivers the distance (the overall delay) from the source network node to the destination network node as the sum of the edge–weights for a given message m over a given route r. The heuristic function h(m, r, e) takes as argument the edge e which had the longest occupation–time for this message (and therefore affected the start time) and tests for all pending messages, whether these have a route using this longest occupied edge. In this case the message length is added to the occupation–prediction value, which is returned by h(m, r, e). The idea is, that edges which are used by many messages can turn out as bottlenecks. The use of edges by multiple messages should be avoided. Evaluated is the sum f (m, r) + h(m, r, e). The message with the lowest evaluation value is selected. In the example (fig. 3) this is for the first step message m2 using route r1 , m1 using r1 for the second step and finally m3 . In worst case, the network is fully meshed. In this case again, there exist 1 + i ∑n−1 i=2 (∏ j=2 (n − j)) routes for each unicast message in a network with n > 1 nodes.

Planning of Time Triggered Communication Schedules

27

For completeness, all these routes have to be considered for scheduling. The search tree has a maximum depth of m, the number of messages. In each depth level one less message has to be considered. The number of nodes in a depth level depends also on the number of routes for each message. In worst case, the search tree expands m−1 i ((m − k) × (1 + ∑n−1 ∑k=0 i=2 (∏ j=2 (n − j)))) nodes. 4.3 Routing with the Dijkstra Algorithm The Dijkstra algorithm [13] is a well known algorithm which solves the shortest path problem on a weighted graph without negative weights. This algorithm can be adapted to deliver not only the shortest path, but several short paths. The idea to get also other shortest paths is to remove edges from the network graph, which were used for the first solution. The algorithm removes for all nodes which are part of the first path and which are accessible by more than one edge the edge that was used for the path and recursively calls the algorithm with the modified graph for each removed edge separately. The drawback of this approach is, that one can specify how deep the recursion shall work, but not how many alternative paths it shall return.

5 Evaluation For evaluation the function portOccupation is of most interest, because this function determines the start time of a message. This function is used for the complete search algorithm as well as for the greedy best–first search heuristic. The number of function calls is directly related to the number of iteration steps the algorithms need for planning the schedules. The quality of a schedule is also important. For evaluation the relative quality (def. 6) is used. 5.1 The Line Topology The line topology is a very popular network topology in industrial automation. In the scenario assumed here, the first network node is a programmable logic controller (PLC) and all other nodes are IO–devices (1 + n). All devices receive in each communication cycle one message and also send one message to the PLC, hence there are double as much messages in the network as devices. Table 1 contains the number of iteration steps per algorithm depending on the network size. A line instead of a number in the table means, that the computation time was longer than 5 minutes on a Pentium 4 Computer (3 GHz, 1 GB RAM, Open SUSE 10.2). It is obvious, that the complete search algorithm can not be used as a scheduling algorithm. For a line-topology with n Devices and 2 messages per device, there are (2 × n)! message permutations which have to be considered. For 4 devices this means 40320 permutations and therefore 8! × 8 iterations, one iteration for each message in each permutation. The schedules created by the greedy best–first search algorithm for such small networks are still optimal and are created in shorter time.

28

O. Graeser, O. Niggemann Number of Devices Complete search iterations Greedy Best–first search iterations 1+2 96 (0.658) 10 (0.658) 1+3 4320 (0.457) 21 (0.457) 1+4 322560 (0.368) 36 (0.368) 1+5 55 (0.317) 1+6 78 (0.264)

Table 1: Number of algorithm–iterations depending on the network size in a line topology (and the relative quality of the schedule)

5.2 Meshed Networks Parallel lines with interconnections can be understood as meshed networks (see fig. 4). Table 2 presents the algorithm iterations necessary to calculate the schedules for such networks. Network type

1 2 3 4 5 6

Complete Search all routes best route

Greedy Best–first search all routes best route with without with or without prediction prediction prediction 276480 (0.63) 4320 (0.66) 42 (0.64) 21 (0.65) 21 (0.64) 591 (0.32) 612 (0.32) 171 (0.29) 2096 (0.22) 2200 (0.25) 351 (0.21) 820 (0.13) 1711 (0.09) 3081 (0.07)

Table 2: Number of algorithm–iterations depending on the network size in a meshed topology (and the relative quality of the schedule)

It is obvious again, that the complete search algorithm cannot be used for scheduling. The search space is even than too big, if only the best route for a message is considered. The greedy best–first search algorithm works good for 2 lines with 4 interconnections (network type 3). After adding a third line, even this algorithm took too long. The bottleneck prediction function calls the measured portOccupation function. But removing this prediction did not reduce the number of algorithm iterations, except for the very small network of type 1. For the network of type 2 the schedules relative quality is the same whether the prediction is used or not, but using the prediction function reduces the number of algorithm iterations. The algorithm using only the best route is faster (171 iterations instead of approx. 600), but the relative quality of the resulting schedule is slightly worse than the other schedules. Considering only the best routes for networks of type 3 resulted in 351 iterations instead of more than 2000 iterations considering all possible routes.

Planning of Time Triggered Communication Schedules

29

The combinational explosion of the greedy best–first search heuristic is based on the huge number of possible paths through the network for a single message. This fact broadens the search tree. For this reason the greedy best–first search algorithm was additionally evaluated by using the best path (or route) through the network. As expected, only considering the best routes, the algorithm works for notable bigger networks. Considering only one route per message implies, that the bottleneck prediction function no longer effects the number of iterations or the schedules in general.

Fig. 4: Network topologies used for evaluation

6 Conclusion and Future Work As mentioned earlier, searching the complete search space is not a viable solution for the planning problem in Profinet IRT. The greedy best–first search algorithm as a first approach to explore the search space in a more problem oriented way, and with a reduced number of routes through the network, provided better results. But still, it is foreseeable that this greedy search algorithm will fail for bigger networks. Hence, it will be necessary for future work to consider additional knowledge about the network and its behaviour in the planning algorithm. For example the optimal schedule for a line of nodes can be calculated and must not be searched. One approach for future work can be to search the network for line topology subnetworks and to predefine the sequence of message which are designated for these subnetworks. This is also important with respect to the Dynamic Frame Packing [14] approach, which increases the Profinet IRT performance by using special knowledge about the communication in line topologies.

30

O. Graeser, O. Niggemann

Future work will also include the investigation of other search algorithms of different approaches as described in [12] and comparing theirs performances. Additionally important aspects of Profinet IRT like message reduction or multicast messages will be included in the planning task.

References 1. Popp, M., Das Profinet IO-Buch – Grundlagen und Tipps für Anwender, Hüthing-Verlag, Heidelberg, 2005 2. Jansen, D., and Büttner, EtherCAT – Der Ethernet-Feldbus, Teil 1: Funktionsweise und Eigenschaften, Elektronik (2003), no. 23, 62–67 3. SERCOS International, Funktionsweise SERCOS III, January 2008,   

     (08.01.2008) 4. Felser, M., Ethernet als Feldbus? Kommunikationsmodelle für industrielle Netzwerke, 2000,        ! (09.01.2009) 5. Janssen, Ethernet-Kommunikation in Echtzeit – Echtzeit ohne Isolation, 2002,  "  #          #  (09.01.2009) 6. Dopatka, F., Ein Framework für echtzeitfähige Ethernet-Netzwerke in der Automatisierungstechnik mit variabler Kompatibilität zu Standard-Ethernet, Ph.D. thesis, Fachbereich Elektrotechnik und Informatik der Universität Siegen, 2008 7. Jasperneite, J., Echtzeit-Ethernet im Überblick, atp – Automatisierungstechnische Praxis 3 (2005) 8. Russel, S. and Norvig, P., Artificial Intelligence – A Modern Approach, second ed., Prentice Hall International, 2003 9. Renner, J., Mobile Agenten für den Fernzugriff auf eingebettete Systeme, Ph.D. thesis, Fakultät für Elektrotechnik und Informationstechnik, TU Chemnitz, 2006 10. Kan, R. and Alexander, H.G., Machine scheduling problems: classification, complexity and computations, The Hague: Nijhoff, 1976 11. Bła˙zewicz, J., Domschke, W. and Pesch, E., The job shop scheduling problem: Conventional and new solution techniques, European Journal of Operational Research (1996), no. 93, 1–33 12. Jain, A.S. and Meeran, S., Theory and Methodology – Deterministic job–shop scheduling: Past, present and future, European Journal of Operational Research (1999), no. 113, 390–434 13. Cormen, T.H., Leiserson, C.E., Rivest, R.L. and Stein, C., Introduction to Algorithms, second ed., MIT Press, 2001 14. Schumacher, M., Jasperneite, J. and Weber, K., A new Approach for Increasing the Performance of the Industrial Ethernet System PROFINET, 7th IEEE International Workshop on Factory Communication Systems (WFCS 2008), Dresden, Germany, 2008, pp. 159–167

Raum-Zeit-Constraints als Programmierabstraktion für Anwendungen in mobilen verteilten Systemen Martin Däumler, Dirk Müller und Matthias Werner TU Chemnitz, Fakultät für Informatik D-09107 Chemnitz

||     

Zusammenfassung. Dieser Beitrag führt eine Programmierabstraktion für Anwendungen in mobilen verteilten Systemen ein. Anwendungen solcher Systeme werden in realer Raum-Zeit abgearbeitet. Dabei werden nicht nur, wie in konventionellen Echtzeitsystemen üblich, zeitliche Bedingungen berücksichtigt. Es müssen zusätzlich räumliche beziehungsweise bewegungsspezifische Anforderungen eingehalten werden. Diese sollen durch Raum-Zeit-Constraints ausgedrückt werden. Die Programmierung derartiger Anwendungen nach dieser Programmierabstraktion wird anhand eines Beispiels demonstriert.

1 Einleitung 1.1 System-Sicht und reale Raum-Zeit Die Entwicklung von Anwendungen für verteilte Systeme stellt Programmierer vor große Herausforderungen. Oftmals muss eine Anwendung in Komponenten aufgeteilt werden und diese den verschiedenen Knoten des ausführenden Systems zugeordnet werden. Müssen diese Knoten kooperieren, ist eine Koordination durch den Programmierer notwendig. Dies macht eine explizite Berücksichtigung der Kommunikation zwischen den Knoten, basierend auf geeigneten Kommunikationsprotokollen, erforderlich. Weiterhin müssen oft Aspekte der Fehlertoleranz der Anwendung gegenüber dem ausführenden System berücksichtigt werden. So sollte beispielsweise der Ausfall eines Knotens nicht die gesamte Anwendung zum Erliegen bringen, sondern lediglich die Qualität des Ergebnisses mindern. In solch einem Fall muss unter Umständen die Anwendung erneut partitioniert und den Knoten zugeordnet werden. Die Berücksichtigung dieser Punkte macht die Programmierung von Anwendungen für verteilte Systeme sehr aufwändig und fehleranfällig. Die Komplexität wird zudem erhöht, wenn die Knoten des ausführenden Systems weitere Freiheitsgrade besitzen, z. B. durch die Einführung von Mobilität. Das ist insbesondere der Fall, wenn die Knoten zur Lösung einer Echtzeit-Aufgabe kooperieren müssen und sowohl eine zeitliche als auch räumliche Koordination der Knoten benötigt wird. Die explizite Berücksichtigung der Verteiltheit eines Systems bezeichnet man als Knoten-Sicht, nach der teilweise in Schwarm-Projekten programmiert wird [7].

32

M. Däumler, D. Müller, M. Werner

Dem gegenüber soll eine System-Sicht wesentliche Verteilungsaspekte des Systems vor dem Programmierer verbergen, d.h. sie transparent machen. Diese Verteilungstransparenz erhöht das Abstraktionsniveau und vereinfacht damit die Arbeit des Programmierers. Anstatt sich der Verteilung des die Anwendung ausführenden Systems bewusst zu sein, soll gegen ein virtualisiertes System programmiert werden. Die Aufteilung der Anwendung in Komponenten und deren Zuordnung auf die einzelnen Knoten des Systems, die Kommunikation zwischen den Konten sowie die zeitliche und räumliche Koordination soll implizit geschehen. Zwei der bekanntesten Echtzeit-Ablaufplanungsverfahren sind Ratenmonotones Scheduling (RMS) und Earliest Deadline First (EDF). Beide Verfahren benötigen zeitbezogene Informationen wie die Periodendauer oder den Sollzeitpunkt einer Task um angewendet werden zu können. In mobilen verteilten Systemen werden jedoch nicht nur zeitbezogene, sondern auch orts- und bewegungsbezogene Anwendungen ausgeführt. Dadurch müssen zeitliche und räumliche Beziehungen und sogar Bewegungen von und zwischen Objekten gemeinsam betrachtet werden. Daher führen wir eine Erweiterung des gängigen Echtzeit-Begriffs ein und sprechen von realer Raum-Zeit. Es handelt sich hierbei um Echtzeitsysteme, die zusätzlich Bedingungen in einer oder mehreren räumlichen Dimensionen berücksichtigen müssen. Die Verteilungstransparenz innerhalb des mobilen verteilten Systems (System-Sicht) und das Mobilitätsbewusstsein innerhalb der Anwendung sind zwei verschiedene Ziele, die idealerweise miteinander in Einklang gebracht werden sollen. Insbesondere die Abstraktion des verteilten Systems und der damit verbundenen impliziten Kommunikation und Koordination der Knoten verlangt eine Unterstützung zur Laufzeit. Da es sich um generische Aufgaben handelt, ist es vorteilhaft, eine verteilte Middleware bzw. ein verteiltes Betriebssystem mit diesen Aufgaben zu betreuen. Dies war die Motivation, das Konzept von FlockOS - Federation of linked objects with common tasks Operating System [14] zu entwickeln, eines Betriebssystems für mobile verteilte Systeme. Diese Publikation ist wie folgt strukturiert: Abschnitt 1 fährt mit der Einführung zweier Anwendungen für FlockOS fort. Abschnitt 2 diskutiert die Anforderungen an eine geeignete Programmierabstraktion, führt die Programmierabstraktion ein und stellt das Laufzeitsystem von FlockOS vor. Danach wird unser Beitrag in bisherige Arbeiten eingeordnet. Die Publikation schließt mit einer Zusammenfassung und einem Ausblick auf zukünftige Arbeiten in Abschnitt 4 ab. 1.2 Beispiel-Anwendungen Eine System-Sicht, wie sie durch FlockOS unterstützt wird, erlaubt eine einfache Entwicklung vielfältiger Anwendungen für mobile verteilte Systeme. Im Verlauf dieser Veröffentlichung werden wir uns durchgehend auf zwei Beispiel-Anwendungen beziehen, die im Folgenden beschrieben werden. Weitere mögliche Anwendungsfälle sind in [15] zu finden. Beispiel 1: Satellitengestützte Beobachtung. Als erstes Beispiel diene die Realisierung eines modernen Kartographie-Systems mittels einem System kooperierender Satelliten. Die Satelliten haben wenige Freiheitsgrade, da sie sich auf fixen Trajektorien bewegen. Es solle ein bestimmtes räumliches Gebiet in einem bestimmten Zeitraum be-

Programmierung mobiler verteilter Systeme

33

obachtet werden. In Abbildung 1 wird dieses Gebiet durch den gestrichelt markierten Bereich gekennzeichnet. Entsprechend der Knoten-Sicht würde in der Steuerungsanwendung geprüft, ob sich ein Satellit gerade in dem fraglichen Bereich befindet. Falls ja, wird mit der Aufzeichnung von Daten begonnen, d.h. die Anwendung wird auf dem Satellit gestartet. Verlässt der Satellit den Bereich, werden die akkumulierten Daten an alle anderen oder an den Satelliten gesendet, der als nächstes die Anwendung ausführt. Die Aufzeichnung der Daten wird eingestellt bzw. die Anwendung ruht auf dem Satelliten. Der Programmierer muss die Migration der Anwendung und die Kommunikation der Satelliten in der Koten-Sicht explizit berücksichtigen. Entsprechend der System-Sicht genügt es als Gesamtanwendung für das Satellitensystem zu beschreiben, dass ein räumliches Gebiet in einem bestimmten Zeitraum beobachtet werden soll. Koordination und Migration der Anwendung sind damit implizit und werden vom Laufzeitsystem übernommen.

90° s0

180°

Erde

0°

Beispiel 2: Roboterfußball. In zahlreichen Roboterfußball-Wettbewerben wird untersucht, s1 wie man Teamanwendungen für mobile verteilte s2 Systeme entwickeln kann. Wir wollen einen bestimmten Aspekt betrachten: Betrachtet man die 270° Anwendung Roboterfußball, so kommt es wieAbb. 1: Anwendung: Kartographie derholt zu Situationen, in denen der Ball an eine bestimmte Position bewegt werden soll und damittels Satellitensystem bei eventuell gegnerische Spieler umspielt werden müssen. Das Umspielen eines (beweglichen) Gegners kann unterschiedlich realisiert werden. So kann der Ball von einem Spieler gedribbelt werden oder es wird ein Doppelpass zwischen zwei Spielern ausgeführt. Die Roboter des mobilen verteilten Systems besitzen mehr Freiheitsgrade als die Satelliten, da die Bewegungen der Roboter frei geplant werden können. Weiterhin ist die Anwendung (der Ball) nicht an eine Position gebunden, sondern diese soll sich während der Ausführung ändern. Dazu müssen die Bewegungen mehrerer Roboter geplant werden. Da es für einen Programmierer mit Knoten-Sicht sehr aufwändig ist jede mögliche Realisierung des Spielzuges bei der Programmierung zu berücksichtigen, wird in einer System-Sicht lediglich der Spielzug bezüglich des relevanten Objektes (des Balls) beschrieben. Die konkrete Umsetzung, d.h. die räumliche und zeitliche Koordination der Roboter ist wieder implizit. Sie kann als eine Ablaufplanungsaufgabe in realer RaumZeit aufgefasst werden. Ablaufplanung (Scheduling) ist eine klassische Aufgabe eines Betriebssystems, entsprechend soll FlockOS hier Unterstützung bieten. Man beachte, dass die Anwendungen dieser Beispiele unterschiedliche Arten von Bewegungsbewusstsein benötigen: Während beim Beobachtungs-Beispiel Bewegung lediglich erlitten wird, muss beim Roboterfußball die Bewegung gesteuert werden.

34

M. Däumler, D. Müller, M. Werner

2 Programmierabstraktion für Anwendungen in realer Raum-Zeit 2.1 Anforderungen an die Programmierabstraktion Die erweiterte Sichtweise auf die Programmierung von Echtzeitsystemen verlangt nach einer neuen Programmierabstraktion um zeitliche, räumliche und bewegungsspezifische Sachverhalte innerhalb einer Anwendung ausdrücken zu können. Konkret muss eine geeignete Programmierabstraktion folgende Eigenschaften haben: A1: Es müssen Eigenschaften der realen Raum-Zeit von und zwischen Objekten beschrieben werden können. Das beinhaltet die Beschreibung von absoluten und relativen Positionen, geometrischen Formen und räumlichen Gebieten. Weiterhin müssen zeitliche Sachverhalte wie frühestmögliche Startzeitpunkte, Sollzeitpunkte, Periodendauern, Zeitintervalle und Präzedenzen ausgedrückt werden. Aufgrund des Mobilitätsbewusstseins innerhalb der Anwendung müssen auch bewegungsspezifische Sachverhalte wie Beschleunigung, Geschwindigkeit oder die konkrete Bewegung (Trajektorie) von und zwischen Objekten formuliert werden können. A2: Die Programmierabstraktion muss die System-Sicht wahren. Diese verbirgt Informationen vor dem Programmierer. Er soll daher nicht beschreiben wie ein Problem im verteilten Fall gelöst wird. Es soll beschrieben werden, was eine Anwendung tun soll. Die Anwendungsbeschreibung muss unabhängig von dem zugrunde liegenden physischen System möglich sein, da FlockOS davon abstrahiert. A3: Die Syntax und Semantik der Programmierabstraktion sollte intuitiv und leicht handhabbar sein um die Akzeptanz zu gewährleisten. Die Abstraktion sollte ähnlich einer domänenspezifischen Programmiersprache sein. Objekte sind in diesem Zusammenhang die mobilen Knoten des Systems und Referenzobjekte, auf die sich die Anwendung bezieht, z.B. der Beobachtungsort im Beobachtungs-Beispiel oder der Ball im Roboterfußball-Beispiel. 2.2 Raum-Zeit-Constraints als Programmierabstraktion Entsprechend der in Abschnitt 2.1 diskutierten Anforderungen an eine Programmierabstraktion erachten wir so genannte Raum-Zeit-Constraints (RZCs) als Erweiterung des Anwendungscodes für vielversprechend. Constraints (englisch: Bedingung, Nebenbedingung, Beschränkung) ermöglichen die Beschreibung unvollständiger Informationen und von Beziehungen zwischen Objekten, was sie für unsere Zwecke entsprechend Anforderung A1 prädestiniert. Constraints haben sich in der Informatik bereits als Programmierabstraktion etabliert [4] und erlauben u. a. das Lösen von Problemen der Ablaufplanung [5, 8]. Konventionelle Echtzeitsysteme drücken beispielsweise ZeitConstraints in Form von Sollzeitpunkten und Präzedenzgraphen aus. In unserem Ansatz sollen RZCs genutzt werden, um die Beschreibung der Sachverhalte entsprechend Anforderung A1 in Abschnitt 2.1 zu realisieren. Damit Programmierer nicht zu weit vom gewohnten Programmierstil abweichen müssen und um Anforderung A3 zu erfüllen, werden RZCs in gewohnten imperativen Code eingebettet. Dazu werden sie Variablen und Datenstrukturen im Anwendungscode, bzw. Operationen auf

Programmierung mobiler verteilter Systeme

35

ihnen, oder ganzen Code-Abschnitten zugeordnet. Die Auswertung der RZCs erfolgt über dem Kontext, d.h. dem Zustand, in dem sich das mobile verteilte System befindet, z.B. die aktuelle Raumzeit eines Knotens. Sie schränken damit zum einen den Kontext ein, innerhalb dessen Anwendungscode ausgeführt wird. Zum anderen spezifizieren RZCs, in welchem Kontext sich ein Objekt nach Ausführung des Anwendungscodes befinden soll, wie beispielsweise die Position des Balls nach einem Spielzug im Roboterfußball. Damit wird erreicht, dass die Ausführung von Anwendungscode beschränkt, bestimmte (zusätzliche) Operationen ausgeführt oder der Ablaufplanungsprozess entsprechend der RZCs beeinflusst wird. Um die Vorteile der RZCs deutlich zu machen, betrachte man Beispiel 1. Dabei wird zum besseren Verständnis bewusst auf die Behandlung von Nebenaspekten verzichtet und der Code so einfach wie möglich gehalten. Die Raumkoordinaten werden auf eine Winkelkoordinate beschränkt. Der Anwendungscode der Kartographie-Anwendung sei wie folgt gegeben: # i n c l u d e < c o n s t r a i n e d v a r . h> # i n c l u d e < s a t e l l i t e s . h> i n t o b s e r v e _ s t a r t = CONST_A ; / / B e g i n n d e s B e o b a c h t u n g s f e n s t e r s i n t o b s e r v e _ e n d = CONST_B; / / Ende d e s B e o b a c h t u n g s f e n s t e r s i n t s e n d _ s t a r t = CONST_C; i n t s e n d _ e n d = CONST_D ;

/ / Beginn des S e n d e f e n s t e r s / / Ende d e s S e n d e f e n s t e r s

c o n s t r a i n t _ p o l c1 ( p h i , p s i , r , t ) = { ( ( i n t ( p h i ) % 3 6 0 ) > CONST_A ) && ( ( i n t ( p h i ) % 3 6 0 ) < CONST_B) } c o n s t r a i n t _ p o l c2 ( p h i , p s i , r , t ) = { ( ( i n t ( p h i ) % 3 6 0 ) > CONST_C) && ( ( i n t ( p h i ) % 3 6 0 ) < CONST_D ) } i n t i@c1 ; i n t s e n d _ t o _ e a r t h ( ) @c2 ;

/ / Rundenzaehler

i n t main ( ) { s t a t i c i n t acc@c1 = 0 ; while ( true ) { accu = accu + r e a d _ s e n s o r ( ) ; i = ( i ++ )% 1 0 0 0 ; i f ( i ==0) s e n d _ t o _ e a r t h ( a c c u ) ; sleep (1); } }

Das Programm hat die folgende Semantik: – Messe jede Sekunde den Messwert und akkumuliere ihn auf. – Sende jede 1000. Runde das Ergebnis an die Bodenstation

36

M. Däumler, D. Müller, M. Werner

Durch den @-Operator wird ein Objekt an das RZC gebunden, in diesem Fall zwei Integer-Variablen und eine Funktion. Die Raumzeit, zu der das jeweilige RZC erfüllt ist, wird jeweils durch einen anderen Satelliten erreicht. Dies bedeutet, dass z. B. der Wert der Variable  zu dem jeweiligen Satelliten übertragen wird. Ereignisse wie update_variable oder block_activity müssen von einem Laufzeitsystem in Abhängigkeit vom Systemzustand und den RZCs ausgelöst werden. Komplizierter ist der Fall im Beispiel 2. Zwar können RZCs in ähnlicher Form angegeben werden, nur reicht die Generierung von entsprechenden Ereignissen zur Laufzeit nicht aus. Vielmehr muss jetzt das Laufzeitsystem das Eintreten von Ereignissen ermöglichen. D. h., der Ablaufplaner muss eine raumzeitliche Zuordnung von Aktivitäten zu Ressourcen realisieren. 2.3 Laufzeitsystem und Codegenerierung Der Code mit der beschriebenen Semantik aus Abschnitt 2.2 zeigt deutlich, dass ein Ansatz, wie er in FlockOS verfolgt wird, auf zwei Ebenen unterstützt werden muss. Zum einen gibt es eine erweiterte Code-Semantik, die bei der Erstellung berücksichtigt werden muss. Andererseits wurde gezeigt, dass zur Laufzeit Ereignisse generiert werden müssen. Entsprechend wird ein Laufzeitsystem benötigt. Laufzeitsystem. Aus den genannten Anforderungen an eine Programmierabstraktion in realer Raum-Zeit und deren Realisierung durch RZCs ergibt sich für das Laufzeitsystem von FlockOS eine Struktur wie in Abbildung 2 illustriert.

Anwendung Laufzeitsystem Ausführungsumgebung Raumzeit-Lokalisierung Kommunikationsschicht

Komponenten Nutzt Dienste von ...

Anwendungs-/Steuerungsdaten

Abb. 2: Laufzeitumgebung von FlockOS

Das Laufzeitsystem stellt Dienste zur Verfügung, die den reibungslosen Ablauf einer Anwendung in realer Raum-Zeit ermöglichen. Es selbst kann verteilt realisiert sein, wovon hier jedoch abstrahiert wird. Den grundlegenden Dienst stellt die Kommunikationsschicht zur Verfügung. Sie ermöglicht den Austausch von Daten zwischen den

Programmierung mobiler verteilter Systeme

37

Knoten und damit erst deren Koordination. Auf diese Kommunikationsschicht muss jeder Knoten des Systems Zugriff haben. Die Kommunikationsschicht wird von der so genannten Raumzeit-Lokalisierung genutzt. Dieser Dienst bestimmt die absoluten und relativen Positionen und Bewegungen der Knoten eines Systems. In gleicher Weise werden die Positionen und Bewegungen von Referenzobjekten, beispielsweise des Balls im Roboterfußball, bestimmt. Die Raumzeit-Lokalisierung nutzt dazu die Kommunikationsschicht, falls beispielsweise ein Konsens der Knoten erforderlich ist. Die so genannte Ausführungsumgebung von FlockOS nutzt die Dienste der Kommunikationsschicht und der Raumzeit-Lokalisierung. Sie ist verantwortlich für das Planen der Aktivitäten der einzelnen Knoten in realer Raum-Zeit. Dazu zählen die Kommunikation zwischen den Knoten und auch das Ausführungen von Bewegungen, falls das möglich ist. Die Aktionen der Ausführungsumgebung sind von den Informationen der RaumzeitLokalisierung und der Semantik der in der Anwendung gegebenen RZCs abhängig. Die Ausführungsumgebung kann jedoch die Dienste der Kommunikationsschicht direkt nutzen. In der Beispielanwendung aus Abschnitt 2.2 nutzt die Ausführungsumgebung Informationen der Raumzeit-Lokalisierung um zu prüfen, wo sich ein Satellit gerade befindet. Ist daraufhin ein RZC erfüllt, wird eine bestimmte Aktion ausgeführt, beispielsweise das Senden der akkumulierten Daten an eine Bodenstation. Das Senden der Daten wird damit an einen bestimmten Raumzeitpunkt bzw. -intervall gebunden. Der Zugriff auf die Variable  wird jedoch verhindert, wenn sich der Satellit nicht im fraglichen Bereich befindet. Somit wird implizit die Ablaufplanung für die Kommunikation und die Anwendung selbst realisiert. In der Ausführungsumgebung erfolgt damit die Abbildung der System-Sicht auf die Knoten-Sicht. Codegenerierung. Die Generierung des im Laufzeitsystem ausgeführten Codes aus dem Anwendungscode kann wie in Abbildung 3 illustriert erfolgen.

Code-Generator SYS.h

Kompilierer Anwendung.csr #include RZC.h #include SYS.h

Anwendung.cpp Präprozessor

Systemprogrammierer

#include RZC.h #include SYS.h

Betriebssystemcode Anwendungscode

Anwendung. app

RZC.h

Anwendungsprogrammierer Zwischencode

Abb. 3: Generierung des verteilten Anwendungscodes

In unserer vorläufigen Implementierung erzeugt ein Präprozessor C++-Code aus der Anwendungsbeschreibung. Eine mit einem RZC annotierte Variable stellt eine Klasseninstanz mit überladenen Operatoren dar. Innerhalb dieser Klasse kann auf eine Funktion

38

M. Däumler, D. Müller, M. Werner

zur Überprüfung des RZC zugegriffen werden, die damit einen Teil der Ausführungsumgebung bildet. Im Beispiel werden Referenz- und Zuweisungsoperationen auf die Variable  verhindert, bis das RZC  erfüllt ist. Bei einer Referenzierung bzw. Zuweisung wird implizit eine Kommunikation angestoßen, um den aktuellen Wert der Variablen zu empfangen bzw. den anderen Knoten mitzuteilen. Die Semantik der RZCs, welche wesentlicher Bestandteil der Ausführungsumgebung ist, wird daher in die Definition einer Klasse verlagert (im Beispiel:   ). Das kann unabhängig von der Anwendung geschehen. Sie kann als eine Bibliothek zur domänenspezifischen Interpretation der RZCs verstanden werden, die der Programmierer geeignet einbinden muss. Zur Beschreibung des ausführenden Systems muss eine Systembeschreibung eingebunden werden (im Beispiel:   ). Sie definiert weitere RZCs, die Fähigkeiten bzw. mögliche Aktionen der Knoten des Systems in realer Raum-Zeit, beispielsweise mögliche Trajektorien oder eine Höchstgeschwindigkeit, beschreiben. Das kann ebenfalls unabhängig von der Anwendung geschehen. Im Fall der KartographieAnwendung sind keine weiteren RZCs anzugeben, da sich die Satelliten auf fixen Trajektorien bewegen. Im Allgemeinen muss die Semantikbeschreibung der RZCs der Anwendung jedoch die möglichen Aktionen des ausführenden Systems berücksichtigen. Das bewirkt, dass diese Beschreibung für die Domäne des ausführenden Systems spezifisch ist. Durch die Trennung von Anwendungs- und Systembeschreibung wird A2 erfüllt, da eine Anwendung damit gegen ein virtualisiertes System programmiert wird.

3 Verwandte Arbeiten Es gibt bereits zahlreiche Möglichkeiten um verteilte Systeme auf Betriebssystem- oder Middleware-Ebene zu unterstützen, zum Beispiel Plan9 [9]. Während diese Ansätze bereits die Verteilung des physischen Systems verbergen, unterstützen sie Mobilität innerhalb der Anwendung jedoch nicht oder nur unzureichend. Das Betriebssystem SwarmOS [7] verfolgt ähnliche Ziele wie unser Projekt, da in dessen Anwendungen die Kooperation mehrerer Knoten erforderlich ist. Jedoch werden dort Anwendungen nach der Knoten-Sicht programmiert und somit muss die Kooperation explizit von dem Programmierer berücksichtigt werden. In [2] wird ein Framework für die Entwicklung mobiler, kontextbewusster Anwendungen vorgestellt. Es werden unter anderem Aspekte der Repräsentation von Kontext, der Abstraktion konkreter Hardwareeigenschaften, der Kommunikation der Knoten des verteilten Systems sowie der Schlussfolgerung anhand von Kontextinformationen betrachtet. Eine aktive bzw. durch die Anwendung steuerbare Bewegung der Knoten des Systems wird jedoch nicht explizit berücksichtigt. Ansätze zur kontextabhängigen Interpretation domänenspezifischer Sprachen sind in [6] zu finden. Sprachkonstrukte werden dabei je nach Zustand, in dem sich das System befindet, anders interpretiert. [13] erläutert, wie Constraint-Programmierung auf Planungsprobleme übertragen werden kann. Es wird verdeutlicht, dass für jede neue Domäne ein neues Modell für die Lösung des Problems erstellt werden muss. Dieser Sachverhalt spiegelt sich in der Beschreibung der Semantik der RZCs innerhalb einer Klassendefinition wider (Abschnitt 2.2). In [10] werden so genannte Constraint Handling Rules (CHR) [3] zur

Programmierung mobiler verteilter Systeme

39

Planung von Multi-Agenten-Systemen verwendet. CHR sind bereits in eine gängige Programmiersprachen wie C [11] integriert. Das macht die Untersuchung von CHR für die Repräsentation und Behandlung von RZCs für zukünftige Arbeiten interessant. Ein Standardwerk zur Behandlung zeitlicher Intervalle stellt Allens IntervallAlgebra dar [1]. In ähnlicher Weise gibt es Arbeiten zum Schlussfolgern über Bewegungen [12]. Diese Betrachtungen beziehen sich jedoch meist auf eine qualitative Repräsentation. Wir benötigen jedoch für Anwendungen, die hohe Anforderungen an die Präzession stellen, auch eine quantitative Repräsentation und einen effizienten Schlussfolgerungsmechanismus darauf.

4 Zusammenfassung und Ausblick Es stellt eine Herausforderung dar, eine Programmierabstraktion für mobile verteilte Systeme zu entwickeln, die die Konzepte der realen Raum-Zeit sowie der SystemSicht unterstützt. Wir schlagen Raum-Zeit-Constraints (RZCs) als Annotationen des nach System-Sicht programmierten Anwendungscodes vor. Es ist dadurch gelungen, die Ausführung einer einfachen Anwendung an räumliche Bedingungen zu knüpfen und eine verteilte Realisierung durch implizite Kommunikation vor dem Programmierer zu verbergen. Dem Programmierer muss jedoch die Semantik der RZCs bekannt sein um sie richtig anwenden zu können. Zudem ist die Beschreibung von Systemen mit mehr Freiheitsgraden durch weitere RZCs wesentlich komplexer als im vorliegenden Beispiel, da hier die Bewegung durch fixe Trajektorien vorgegeben ist. Eine große Herausforderung stellt die Beschreibung der Semantik der in der Anwendung gegebenen RZCs dar, wenn diese zur impliziten Ablaufplanung, z.B. von Bewegungen, genutzt werden müssen. Im Beispiel wurde lediglich implizite Kommunikation realisiert. Die weiteren Schritte umfassen auf der einen Seite die Entwicklung eines geeigneten Modells zur Repräsentation räumlicher, zeitlicher und bewegungsspezifischer Sachverhalte. Darauf aufbauend wird die endgültige Syntax der RZCs festgelegt. Bei der Nutzung spezieller Sprachen zur Behandlung und Darstellung von Constraints ist auf eine geeignet Integration in gängige Programmiersprachen zu achten. Auf der anderen Seite müssen Methoden zum impliziten Finden eines Ablaufplanes entwickelt werden. Hier ergeben sich Ansatzpunkte in der Kompilierertechnik.

Literaturverzeichnis 1. Allen, J.: Maintaining knowledge about temporal intervals. In „Communication of the ACM“, 26(11):832–843, 1983. 2. Biegel, G., und Cahill, V.: A framework for developing mobile, contextaware applications. In „PERCOM ’04: Proceedings of the Second IEEE International Conference on Pervasive Computing and Communications (PerCom’04)“, S. 361, Washington, DC, USA, 2004. 3. Frühwirth, T.: Theory and practice of constraint handling rules. In „Journal of Logic Programming, Special Issue on Constraint Logic Programming“, 37(1-3):95– 138, October 1998. 4. Frühwirth, T., und Abdennadher, S.: Constraint Programmierung – Grundlagen und Anwendungen. Springer, Berlin/Heidelberg, 1997.

40

M. Däumler, D. Müller, M. Werner

5. Hesselink, H., und Paul, S.: Planning aircraft movements on airports with constraint satisfaction, 1998. 6. Laird, P., und Barrett, S.: Towards context sensitive domain specific languages. In „CAMS ’09: Proceedings of the 1st International Workshop on Context-Aware Middleware and Services“, S. 31–36, New York, NY, USA, 2009. ACM. 7. McLurkin, J.: Stupid Robot Tricks: A Behavior-Based Distributed Algorithm Library for Programming Swarms of Robots. PhD thesis, Massachusetts Institute of Technology, Department of Electrical Engineering and Computer Science, 2004. 8. Le Pape, C.: Constraint-based scheduling: A tutorial, 2005. 9. Pike, R., Presotto, D., Thompson, K., und Trickey, H.: Plan 9 from bell labs. In „Computing Systems“, 8(3):221–254, 1995. 10. Seitz, C., Bauer, M., und Berger, M.: Multi agent systems using constraint handling rules for problem solving, 2002. 11. Sneyers, J., Van Weert, P., Schrijvers, T., und De Koninck, L.: As time goes by: Constraint Handling Rules – A survey of CHR research between 1998 and 2007, 2009. 12. Van De Weghe, N., Cohn, A., De Tré, G., und De Maeyer, P.: A qualitative trajectory calculus as a basis for representing moving objects in geographical information systems. In „Control and Cybernetics“, 35(1):97–119, 2006. 13. Van Beek, P., und Chen, X.: CPlan: A constraint programming approach to planning. In AAAI/IAAI, S. 585–590, 1999. 14. Werner, M., Müller, D., Däumler, M., Richling, J., und Mühl, G.: Operating system support for distributed applications in real space-time. In „Workshop on Autonomous and Autonomic Software-based Systems (ASBS) at the IEEE International Conference on Soft Computing as Transdisciplinary Science and Technology“, S. 469–478, 2008. 15. Werner, M., Richling, J., Müller, D., und Mühl, G.: Towards a holistic approach for distributed real space-time systems. In „International Workshop on Dependable Network Computing and Mobile Systems at the 27th International Symposium on Reliable Distributed Systems“, S. 63–67, 2008.

Formale Bestimmung von Systemparametern zum transparenten Scheduling virtueller Maschinen unter Echtzeitbedingungen Timo Kerstan, Daniel Baldin und Gunnar Schomaker Heinz-Nixdorf-Institut, Fürstenalle 11, 33102 Paderborn           

Zusammenfassung. Nicht nur im Bereich der Server-Konsolidierung, sondern auch innerhalb eingebetteter Systeme findet die Virtualisierung immer mehr Einzug. Dabei werden virtuelle Maschinen sehr häufig mit Hilfe eines Zeitscheibenverfahrens abwechselnd ausgeführt. Gerade der Bestimmung der Systemparameter, wie beispielsweise der Zeitscheibe, kommt dabei eine sehr große Bedeutung zu und stellt häufig ein Problem dar. Mit Hilfe unserer Verfahren ist es nun möglich, aus einer Menge gegebener Echtzeitsysteme ein neues Echtzeitsystem zu definieren, welches durch den Einsatz von Virtualisierungtechniken in der Lage ist, sämtliche Echtzeitsysteme in Form virtueller Maschinen auf einem Mikrokontroller auszuführen. Dabei bleiben die Echzeiteigenschaften der einzelnen Echtzeitsysteme erhalten.

1 Einleitung Der Einsatz von Virtualisierungtechniken im Desktop- und Servermarkt ist mittlerweile nicht mehr nur ein Trend, sondern Realität. Es gibt eine Vielzahl von Produkten, die z. B. Virtualisierung von Betriebssystemen sowohl für normale Anwender als auch für Systemadministratoren zur Verfügung stellen. Diese erlauben es z. B. ganze Serverfarmen zu konsolidieren und mehrere Server auf einem leistungsfähigen Server auszuführen. Dadurch kann eine bessere Auslastung der Hardwareresourcen und ein geringerer Energieverbrauch erreicht werden. Eingebettete Systeme aus der Automobil- und Luftfahrtindustrie bestehen meist aus komplexen Mikrokontrollernetzwerken, wobei jeder Mikrokontroller häufig nur eine dedizierte Aufgabe übernimmt und damit nur wenig ausgelastet ist. Diese Trennung wird insbesondere wegen der Sicherheit des Gesamtsystems vorgenommen, damit eine fehlerhafte Komponente nicht in der Lage ist, eine andere Komponente negativ zu beeinflussen. Der Einsatz von Virtualisierungstechniken in eingebetteten Systemen wird mittlerweile jedoch stark vorangetrieben und ermöglicht eine temporale als auch eine räumliche Trennung der virtuellen Maschinen, womit die Sicherheit und Zuverlässigkeit bei Ausführung mehrerer Komponenten auf einem einzigen Mikrokontroller stark gesteigert wird. Damit ist eine Verteilung auf verschiedene Mikrokontroller nicht mehr zwingend erforderlich. Zusätzlich zur Steigerung der

42

T. Kerstan, D. Baldin, G. Schomaker

Sicherheit und Zuverlässigkeit ermöglicht die Virtualisierung die einfache Unterstützung für heterogene Betriebssystemumgebungen, um den konkurrierenden Anforderungen nach High-Level API’s für die Applikationsentwicklung, Echtzeitbedingungen und Unterstützung für Legacy-Software gerecht zu werden. Ebenso wird durch den Einsatz von Virtualisierung die Skalierbarkeit auf Hardwareresourcen verbessert, da diese durch die Virtualisierungsplattform den unterschiedlichen virtuellen Maschinen nach Bedarf zugewiesen werden können. Allerdings können die Verfahren aus dem Bereich der Server- und Desktopvirtualisierung nicht 1:1 übernommen werden, da eingebettete Systeme in der Regel strikten Echtzeitbedingungen genügen müssen. Das Scheduling virtueller Maschinen, die unter Echtzeitbedingungen ausgeführt werden müssen, wird derzeit in sehr vielen Fällen durch eine statische Partitionierung mit Fixed Time Slice Scheduling realisiert [6]. Dabei wird den entsprechenden virtuellen Maschinen a priori ein fester Anteil Prozessorzeit zugewiesen. Dadurch wird gewährleistet, dass die virtuelle Maschine auf eine deterministische Art und Weise aktiviert wird. Die einzelnen virtuellen Maschinen erleiden in der Zeit, in der Sie nicht aktiv sind, einen Blackout, da in diesem Zeitraum die reale Zeit weiterläuft, aber die logische Zeit der virtuellen Maschine anhält. Dieser Blackout muss bei der WCET Analyse berücksichtigt werden und hängt von der Anzahl der verbleibenden virtuellen Maschinen und deren belegten Zeitslots ab. In [5] wurde der Einfluss dieser Blackouts auf die Ausführungszeit thematisiert und aufgezeigt, welchen Einfluss die Virtualisierung insbesondere auf die Verzögerung der Echtzeittasks eines Mikrokontrollers haben können, wenn dieser nun anstatt einer dedizierten Aufgabe weitere virtuelle Maschinen aufnehmen muss. Es wird jedoch nicht darauf eingegangen, wie zusätzliche virtuelle Maschinen in das System integriert werden können, um die gegebenen Echtzeitbedingungen weiter einzuhalten. Wir zeigen im folgenden eine Methode, die es erlaubt, aus einer Menge gegebener Echtzeitsysteme ein neues Echtzeitsystem zu bestimmen, welches die bereits vorhandenen Echtzeitsysteme als virtuelle Maschinen aufnimmt und ausführt. Das Echtzeitscheduling innerhalb der einzelnen virtuellen Maschinen bleibt dabei unangetastet, so dass die Virtualisierung völlig transparent als Vollvirtualisierung vorgenommen werden kann. Dies bietet den Vorteil, dass es nicht notwendig ist, die Gastsysteme anzupassen, wie es im Falle der Paravirtualisierung nötig wäre. Die von unserem Ansatz bestimmten Parameter des Zielsystems sind: – Geschwindigkeit des Controllers – Zeitliche Granularität Diese Eigenschaften werden mit der Restriktion bestimmt, dass weiterhin die Echtzeitbedingungen der ursprünglichen Systeme eingehalten werden. Dazu werden Informationen über die Leistungsfähigkeit der zu virtualisierenden Echtzeitsysteme benötigt. Momentan wird zur Vereinfachung ein einfaches Modell, bei dem die Taktfrequenz das ausschlaggebende Maß für die Geschwindigkeit darstellt, verwendet. Effekte, wie z. B. Pipelining und Caching werden vernachlässigt. Des Weiteren werden die Worst Case Execution Times und die Echtzeitschranken aller Echtzeittasks der zu virtualisierenden Echtzeitsysteme benötigt. Zur Bestimmung der benötigten zeitlichen Granularität beim Scheduling der virtuellen Maschinen wird ein Zeitintervall bestimmt. Die besondere Eigenschaft dieses Intervalls ist, dass es zu keinerlei Verletzung der Echtzeitschranken innerhalb der vorhandenen virtuellen Maschinen kommt. Das Zeitintervall wird dazu

Transparentes Scheduling virtueller Maschinen

43

Abb. 1: Durch ungünstige Wahl der Zeitscheibe H können Echtzeitschranken verletzt werden.

in feste Zeitslots entsprechend der benötigten Rechenzeit für jede virtuelle Maschine aufgeteilt. Mit Hilfe unserer Methode ist es damit möglich, aus einer Menge gegebener Echtzeitsysteme ein neues Echtzeitsystem zu definieren, welches durch den Einsatz von Virtualisierungtechniken in der Lage ist, sämtliche Echtzeitsysteme in Form virtueller Maschinen auf einem Mikrokontroller auszuführen. Dabei bleiben die Echtzeiteigenschaften der einzelnen Echtzeitsysteme erhalten, ohne dass eine Anpassung an den Gastsystemen vorgenommen werden muss.

2 Verwandte Arbeiten Kaiser beschreibt in [5, 6] ein Verfahren zum Scheduling virtueller Maschinen in eingebetteten Echtzeitsystemen mit Hilfe von Paravirtualisierung. Das Verfahren basiert auf Proportional-Share Zuteilung und erlaubt es, ereignisgesteuerte und zeitgesteuerte virtuelle Maschinen mit Echtzeitbeschränkungen auf einem System auszuführen. Dabei werden die virtuellen Maschinen mit Prioritäten versehen und in Zeitdomänen eingeteilt. Die Zeitdomänen werden mittels Round Robin aktiviert. Innerhalb einer aktiven Zeitdomäne wird die aktive virtuelle Maschine mit der höchsten Priorität entsprechend ihrem zugeteilten Proportional-Share Gewicht ausgeführt. Um ereignisbasierten virtuellen Maschinen eine geringe Verzögerung zu garantieren, werden diese in eine Hintergrunddomäne eingeordnet, die permanent aktiv ist. Wird nun eine ereignisgesteuerte virtuelle Maschine aus der Hintergrunddomäne aktiv, so kann sie eine gerade ausgeführte zeitgesteuerte virtuelle Maschine verdrängen, wenn Sie eine höhere Priorität besitzt. Jedoch wird nicht darauf eingegangen, wie die Zeitscheibenlängen gewählt werden müssen, um die Echtzeitschranken sämtlicher virtuellen Maschinen einhalten zu können. Durch ungünstige Konstellationen ist es jedoch möglich, dass trotz passender Gewichtung mittels Proportional-Share Echtzeitschranken verfehlt werden können. Ein Beispiel für eine solche Konstellation ist in Abbildung 1 dargestellt. In dem dort betrachteten Szenario gibt es zwei virtuelle Maschinen, welche abwechselnd mit einer

44

T. Kerstan, D. Baldin, G. Schomaker

Zeitscheibe von H = 4 Zeiteinheiten ausgeführt werden. Die erste virtuelle Maschine beinhaltet zwei Anwendungen. Einen Task mit Ausführungszeit eins und einen mit Ausführungszeit drei. Beide Anwendungen haben jeweils eine Periode und Echtzeitschranke von acht Zeiteinheiten. Die zweite virtuelle Maschine führt zwei Anwendungen mit zwei bzw. drei Zeiteinheiten Ausführungszeit und einer Periode bzw. Echtzeitschranke von 10 Zeiteinheiten aus. Beide virtuelle Maschinen besitzen die selbe Auslastung und erhalten jeweils die Hälfte der Zeitscheibe H als Ausführungszeit zugewiesen. Bedingt durch die ungünstige Wahl der Zeitscheibe verpasst jedoch Task vier seine Echtzeitschranke, da diese virtuelle Maschine zum Zeitpunkt 10 nicht den benötigten Anteil an Prozessorzeit erhalten hat. Solche Fälle wollen wir im folgenden mit Hilfe der durch unsere Modellierung bestimmten Systemparameter ausschließen. Wir gehen, im Gegensatz zu dem in diesem Abschnitt vorgestellten Ansatz, nicht von einer Anpassung des Gastsystems zur Paravirtualisierung aus.

3 Modellierung des Systems Als Modellierungsgrundlage verwenden wir eine globale Menge von Prozessen (weiterhin auch Anwendung oder Task genannt)

τ = {(C, T )|C, T ∈ R ∧C ≤ T } t ∈ τ = (Ct , Tt ),

(1) (2)

deren Echtzeitschranken gleich ihrer Periodendauer T sind. Jede virtuelle Maschine V Mi kann eine Teilmenge dieser Prozesse aufnehmen und mittels ihrer lokalen Schedulingpolicy verwalten. V Mi ⊆ τ , i ∈ {1, ..., n}

(3)

Wir nehmen zur Vereinfachung an, dass alle virtuellen Maschinen ursprünglich auf gleichschnellen Systemen ausgeführt werden und dass sie ihr System nicht überlasten. UV Mi =

Cj ≤1 j∈V Mi T j

∑

(4)

Sollten die Ausgangssysteme nicht gleich schnell arbeiten, ist vorher eine Skalierung der Task-Ausführungszeiten auf ein gemeinsames Basissystem durchzuführen.

4 Abbildung auf ein neues System Sei nun eine Menge von virtuellen Maschinen gegeben, welche zusammen auf einem System ausgeführt werden soll. Die Gesamtauslastung für den Fall, dass sämtliche virtuelle Maschinen auf einem einzigen System ausgeführt würden, beträgt dann ohne Berücksichtigung von Wechselzeiten zwischen den virtuellen Maschinen: n

Uges = ∑ UV Mi ≤ n i=1

(5)

Transparentes Scheduling virtueller Maschinen

45

Für den hier betrachteten Fall Uges > 1, muss das neue System um den Faktor s = Uges schneller sein, damit das neue System nicht überlastet wird. Durch diesen Geschwindigkeitsgewinn verkürzen sich die Ausführungszeiten der Prozesse und man erhält eine neue Menge von Prozessen τ  auf dem neuen System:    Ct , Tt |t ∈ τ (6) τ = s    Ct V Mi = , Tt |t ∈ V Mi (7) s Bezogen auf ein um den Faktor s schnelleres System ergibt sich die Auslastung einer beliebigen virtuellen Maschine zu: UV Mi =

Cj 1 = s · T s j j∈V Mi

∑

Cj 1 = ·UV Mi T s j j∈V Mi

∑

(8) (9)

Die Auslastung des neuen Gesamtsystems ergibt sich, wie erwartet, zu:  = Uges

1 n 1 UV Mi = ·Uges = 1 ∑ s i=1 s

(10)

Das Scheduling der virtuellen Maschinen wird mittels eines Zeitscheibenverfahrens realisiert. Dabei erhält jede virtuelle Maschine V Mi ihren Anteil UV Mi innerhalb eines zeitlichen Intervalls mit fester Länge H. Der Aktivierungszeitpunkt der jeweiligen virtuellen Maschine V Mi innerhalb dieses Intervalls ist dabei beliebig. Die Periodendauer einer virtuellen Maschine V Mi ergibt sich so zu: TV Mi =

UV Mi  Uges

·H

(11)

Das Verhältnis zwischen dem Zeitslot der virtuellen Maschine V Mi und dem umschließenden Intervall H entspricht dabei dem ursprünglichen Verhältnis der Auslastung der einzelnen VM zur Auslastung des Gesamtsystems. Dies zeigt, dass die verfügbare Rechenzeit für jede virtuelle Maschine V Mi erhalten bleibt. TV Mi H

=

UV Mi  Uges

=

UV Mi Uges

(12)

Die Ausführungsreihenfolge der virtuellen Maschinen innerhalb dieses Intervalls spielt für die Einhaltung der Echtzeitschranken keine Rolle. Lediglich die Antwortzeit einer virtuellen Maschine kann durch eine frühere Ausführung reduziert werden. Abbildung 2 a) zeigt die Entwicklung der Ausführungszeit einer virtuellen Maschine beispielhaft. Einen entsprechenden Schedule, innerhalb eines neuen Systems, zeigt Abbildung 2 b).

46

T. Kerstan, D. Baldin, G. Schomaker

Abb. 2: a) Entwicklung der virtuellen Ausführungszeit CV Mi . b) Entsprechender Schedule der virtuellen Maschinen. Innerhalb des periodischen Intervalls H werden die virtuellen Maschinen V Mi über einen Zeitraum von TV Mi ausgeführt. Der Wahl der Länge H kommt große Bedeutung zu, da innerhalb der virtuellen Maschinen V Mi harte Echtzeittasks geplant werden müssen. Wir wählen die Länge des Intervalls H wie folgt: H = ggT ({Tt |t ∈ τ  }) ⇒ Tt = c · H, c ∈ N

+

(13) (14)

Da die Echtzeitschranke Tt eines beliebigen Prozesses ein Vielfaches von H ist, wird U Mi garantiert, dass jede virtuelle Maschine V Mi bis zu diesem Zeitpunkt ihren Anteil UVges der Prozessorzeit zugewiesen bekommt. Dies wiederum garantiert die Einhaltung der Echtzeitschranken der Tasks innerhalb der virtuellen Maschinen. 4.1 Beispiel Betrachten wir nun beispielhaft eine Ausgangsmenge von Tasks

τ = {(1, 4), (2, 4), (3, 8), (1, 4)} , welche ursprünglich auf zwei Systemen ausgeführt wurde mit V M1 = {τ1 , τ2 } und V M2 = {τ3 , τ4 }. Die Auslastung auf dem ersten System betrug dabei U1 = 34 bzw.

Transparentes Scheduling virtueller Maschinen

47

Abb. 3: Der Schedule der virtuellen Maschinen auf dem neuen System aus dem Beispiel.

U2 = 58 auf dem zweiten System. Eine gemeinsame Ausführung der Tasks auf einem System wäre nicht möglich, da U1 +U2 = 11 8 > 1. Es muss also ein schnelleres System verwendet werden, um die virtuellen Maschinen zusammen auf einem neuen System ausführen zu können. Dieses System muss dabei um den Faktor s = 11 8 schneller arbeiten. Auf dem neuen System ergeben sich für die Anwendungen entsprechend verkürzte Ausführungszeiten und man erhält nach Formel (6) eine neue Menge von Tasks         16 24 8 8  ,4 , ,4 , ,8 , ,4 τ = 11 11 11 11 Da die virtuellen Maschinen nun über ein Zeitscheiben-Verfahren auf dem neuen System abwechselnd ausgeführt werden, müssen die jeweiligen Zeitscheiben T1 , T2 entsprechend der Auslastung der virtuellen Maschinen nach Formel (11) berechnet werden. Für die Zeitscheiben-Periode H ergibt sich nach Formel (13) der Wert H = 4. In6 · 4 = 24 nerhalb dieser Periode erhält V M1 ein Zeitintervall von T1 = 11 11 und V M2 einen 5 20 Anteil von T2 = 11 · 4 = 11 Zeiteinheiten. Der entsprechende Schedule ist in Abbildung 3 dargestellt. Durch die Wahl der Zeitscheibe H und der Zeitintervalle T1 bzw. T2 ist nun sichergestellt, das alle Echtzeitschranken der Anwendungen auf dem neuen System eingehalten werden, ohne dabei das Scheduling-Verfahren innerhalb der virtuellen Maschinen verändern bzw. kennen zu müssen.

5 Zukünftige Arbeiten Das hier vorgestellte Verfahren wird zur Zeit in die von der Universität Paderborn entwickelten Virtualisierungs-Plattform Proteus [2] integriert. Im Zuge dieser Umsetzung ergeben sich neue Probleme bezüglich der Diskretisierung der Zeitintervalle und Perioden. Weiterhin müssen Lösungsansätze gefunden werden für den Fall, dass die Zeitscheibe H zu klein ausfällt. Darüber hinaus betrachtet das Verfahren nur eine Teilmenge der möglichen Anwendungsfälle, da die Periode der Echtzeitanwendungen gleichzeitig die Echtzeitschranke darstellt. Das Verfahren soll daher entsprechend erweitert werden, um Anwendungen mit beliebigen Echtzeitschranken garantieren zu können.

48

T. Kerstan, D. Baldin, G. Schomaker

Literaturverzeichnis 1. Virtualization for embedded systems. Technical report, Open Kernel Labs, Apr 17, 2007. 2. D. Baldin and T. Kerstan. Proteus, a hybrid virtualization platform for Embedded Systems. Springer, 2009. 3. G. C. Buttazzo. Hard Real-Time Computing Systems. Springer, 2004. 4. R. Greene and G. Lownes. Embedded CPU target migration, doing more with less, 1994. 197743 429-436. 5. R. Kaiser. Alternatives for scheduling virtual machines in real-time embedded systems, 2008. 1435460 5-10. 6. R. Kaiser. Applying virtualization to real-time embedded systems. 1. GI/ITG KuVS Fachgespräch Virtualisierung, 2008. 7. J. E. Smith and R. Nair. Virtual Machines – Versatile Platforms for Systems and Processes. Morgan Kaufmann, 2005.

Anwendung von Methoden der Logistik und Netzplantechnik zur präzedenz- und ressourcenbeschränkten Ablaufplanung von Echtzeitsystemen Roman Gumzej und Martin Lipiˇcnik Fakultät für Logistik, Universität zu Maribor Mariborska cesta 7, 3000 Celje/Slowenien   

Zusammenfassung. Grundlegende Zusammenhänge zwischen Logistik, Netzplantechnik und Echtzeit sowie den zugehörigen Arten der Ablaufplanung und ihrer Nutzung werden dargestellt. Das Echtzeitprinzip beinhaltet Rechtzeitigkeit von Abläufen, wobei es für eine frühzeitige Beendigung eines Ablaufs keinen Bonus gibt; im Gegensatz zum verspäteten Ablauf, dessen Konsequenzen in der Regel negativ und unabschätzbar sind. Das Just-in-Time-Prinzip gleicht dem der Echtzeit und wird vor allem in der Logistik zur Bezeichnung reibungsloser Abläufe in Beschaffungsketten verwendet. In der Netzplantechnik werden die kritischen Aktivitäten binnen eines Projektes bestimmt, die nicht verzögert werden dürfen, um das Projekt rechtzeitig zu beenden. Außerdem haben die drei Bereiche noch eine Gemeinsamkeit: um realistische Ablaufszenarien darzustellen, müssen in den Analysen auch begrenzte Ressourcen angemessen berücksichtigt werden.

1 Einleitung Zur Planung der Abläufe in Echtzeitsystemen ist es üblich, eines der in Tabelle 1 genannten Zuteilungsverfahren zu benutzen. Die genannten Ablaufplanungsalgorithmen dienen alle demselben Zweck, nämlich die Prozesse eines Systems in einer solchen Reihenfolge abzuwickeln, dass ihre Fertigstellungsfristen alle eingehalten werden. Soweit die Nutzung des Prozessors es erlaubt, können im Prinzip alle genannten Verfahren ihren Zweck mehr oder weniger gut erfüllen. Das Optimalitätskriterium ist für alle gleich – rechtzeitige Durchführung der Prozesse. Es gibt keinen Bonus für vorzeitige Prozessbearbeitung. Auf der anderen Seite jedoch werden verspätete Abläufe überwiegend als minderwertig wenn nicht sogar als schädlich betrachtet. Wenn wir es mit untereinander abhängigen Prozessen zu tun haben, die eventuell noch auf mehreren Prozessoren ausgeführt werden, so verlangt nach allgemeiner Ansicht die Ablaufplanung solcher Prozesse einen NP-vollständigen Algorithmus [1].

50

R. Gumzej, M. Lipiˇcnik

Tabelle 1: Ablaufplanung in verschiedenen Disziplinen Bereich

Verfahren

Ressourcenberücksichtigung

Einsatz

Echtzeitsysteme Projektplanung Produktionsplanung

RM, EDF, LLF CPM JIT, EOQ

Zuteilbarkeitsanalyse CCPM JIS

statisch, dynamisch statisch, dynamisch statisch, dynamisch

Die oben genannten Verfahren zur Ablaufplanung für Echtzeitsysteme setzen Prozesse als unabhängige Aktivitäten voraus. Abhängigkeiten vom Typ Start-Start, EndeStart oder Ende-Ende werden bei der Ablaufplanung nicht berücksichtigt. Jegliche Art der Synchronisation oder Kommunikation, die Ressourcenabhängigkeiten darstellen, wird daher als unerwünscht betrachtet, minimiert oder sogar vermieden. Um Ressourcenabhängigkeiten mit einzubeziehen, werden Techniken der statischen Zuteilbarkeitsanalyse eingesetzt, die aber nur beschränkt anwendbare suboptimale Lösungen liefern können. In der Netzplantechnik wurde die CPM-Methode [2] zur Ablaufplanung zeitlich befristeter Aktivitäten innerhalb eines Projektes entwickelt. Der damit verbundene „kritische Pfad“ wurde von der gleichnamigen Methode abgeleitet und stellt die Sequenz der Prozesse dar, deren Ablauf nicht verzögert werden darf, um die Rechtzeitigkeit des Projektes zu gewährleisten. Um sporadische Ereignisse und Ressourcenabhängigkeiten mit einzubeziehen, wurde die Methode der „kritischen Kette“ (CCPM) [3] geschaffen. Bei letzterer geht es darum, sich wie bei CPM vom geplanten Projektende aus vorzuarbeiten, um letztmögliche Startzeiten der Aktivitäten zu bestimmen. In der Gegenrichtung werden die erforderlichen Betriebsmittel eingeplant. Den längsten Pfad, der die Aktivitätsreihenfolge mit deren Präzedenz- und Ressourcenbeschränkungen darstellt, nennt man „kritische Kette“. Man nimmt an, dass dabei etwa die Hälfte der Aktivitäten nicht verzögert wird. Mit dieser fünfzigprozentigen Reserve werden auf Projektebene so genannte Puffer eingeführt, die bei Projektmeilensteinen verwaltet werden, um auf Zeitreserven zu prüfen. In der Logistik wurde das Just-In-Time-Prinzip (JIT) eingeführt, das zur Bestimmung optimaler Bestellmengen bei gegebenem Bedarf im Zusammenhang mit dem Konzept der Economic Order Quantity (EOQ) steht. Die Basis der JIT-Philosophie [4] ist die Minimierung „wertlosen“ und „teueren“ Inventars. Aktivitäten werden im Produktionsablauf so eingeplant, dass „richtige“ Betriebsmittel zur „richtigen“ Zeit am „richtigen“ Platz in „richtiger“ Menge vorhanden sind. Jedes Aufstauen von Inventar wird als sinnlose Verschwendung angesehen und ist von der Planung her suboptimal, wenn nicht gar inakzeptabel. Dieses Konzept wurde durch das Just-In-Sequence-Prinzip (JIS) erweitert, das zusätzlich erfordert, Betriebsmittel in der von den Produktionsprozessen verlangten Reihenfolge bereitzustellen. Da die Betriebsmittel vorhanden und ihre Bereitstellung spätestens dann beendet sein soll, wenn der Beginn einer Aktivität eingeplant ist, wird Warten vermieden. Aus diesen Kurzbeschreibungen kann man entnehmen, dass es in allen drei Bereichen um dasselbe Problem „Ablaufplanung unter Präzedenz- und Ressourcenbeschränkungen“ geht, das man je nach Anwendungsbereich unabhängig voneinander und un-

Methoden der Logistik, Netzplantechnik und Echtzeit

51

terschiedlich zu lösen versucht hat. Der Zweck dieses Beitrags ist es daher, die Verfahren auf denselben Nenner zu bringen und die besten Praktiken zur „präzedenz- und betriebsmittelbewussten“ Ablaufplanung für Echtzeitsysteme zu identifizieren. Obwohl z. B. CPM und JIS auch zur dynamischen Projekt- und Prozessverwaltung benutzt werden, betrachtet man die meisten oben genannten Verfahren aus Netzplantechnik und Logistik als statische Ablaufplanungsmethoden. Trotzdem hat sich z. B. das JIT/JIS-Verfahren auch als für industrielle Prozesse mit Unterbrechungen in der Produktionskette gut geeignet erwiesen (vgl. Toyota Production System [5]). Da Echtzeitsysteme in der Prozessindustrie breiten Einsatz finden, ist zu vermuten, dass die bei der Planung der von ihnen gesteuerten Prozesse verfolgten Prinzipien auch für die Ablaufplanung ihrer Automatisierungssysteme einsetzbar sein sollten. In den folgenden Abschnitten wird die Anwendung der genannten Techniken aus der Logistik und Netzplantechnik genauer untersucht, um festzustellen, inwieweit und ggf. mit welcher Qualität sie sich zur Ablaufplanung von Echtzeitprozessen bei eingeschränkter Verfügbarkeit von Ressourcen eignen. Da es sich bei der Ablaufplanung in allen drei Bereichen um eine grundlegende Aufgabenstellung handelt, werden im Ausblick gemeinsame Aspekte der Logistik hervorgehoben, auf die Prinzipien der Echtzeit anzuwenden sind.

2 Ablaufplanung unter Präzedenz- und Ressourceneinschränkungen Die in der Einleitung genannten Ablaufplanungsverfahren für Echtzeitsysteme setzen Prozesse als unabhängige Aktivitäten voraus. Abhängigkeiten der Typen Start-Start, End-Start, End-End werden bei der Ablaufplanung nicht berücksichtigt. Jegliche Art der Synchronisation oder Kommunikation, die Ressourcenabhängigkeiten darstellt, wird daher als unerwünscht betrachtet und minimiert oder sogar vermieden. Um Ressourcenabhängigkeiten in die Analyse mit einzubeziehen, wurden Techniken der statischen Zuteilbarkeitsanalyse eingesetzt, die aber nur beschränkt anwendbare suboptimale Lösungen bieten können. Obwohl Ablaufplanungsverfahren der Logistik und Netzplantechnik auch zur dynamischen Prozess- und Projektverwaltung benutzt werden, betrachtet man die meisten oben genannten Verfahren als statische Ablaufplanungsmethoden. Trotzdem hat sich z. B. das JIT/JIS-Verfahren auch für industrielle Prozesse mit Unterbrechungen in der Produktionskette durch die verbesserte Rechtzeitigkeit der Abläufe sowie die ständig abnehmende Anzahl von Unterbrechungen als gut geeignet erwiesen. In der Folge wird ein Verfahren vorgestellt, das die guten Eigenschaften aller genannten Ablaufplanungstechniken vereinen soll, nämlich Rechtzeitigkeit und Ressourceneinbindung. Rechtzeitigkeit bezieht sich sowohl auf die erstellten Ablaufszenarien als auch auf den Prozess ihrer Erstellung. Es werden dabei keine optimalen Lösungen gesucht, da sie laut Literatur nicht in vorhersehbarer Zeit gefunden werden können. Die Lösungen, die dabei berechnet werden und das Echtzeitprinzip erfüllen, werden als „gut genug“ betrachtet und können in polynomialer Zeit gewonnen werden.

52

R. Gumzej, M. Lipiˇcnik

3 Hybrides Verfahren zur Ablaufplanung von Echtzeitsystemen Ziel ist die Erstellung einer Strategie zur ressourcenbewussten Ablaufplanung in Anbetracht der genannten JIT/JIS-Prinzipien. Durch Ablaufplanung sollen Szenarien erstellt werden, in denen für die Prozesse zur Zeit ihrer Aktivierung die benötigten Ressourcen bereitstehen. Die Vorgehensweise gleicht der von CPM: zuerst werden frühest- und letztmögliche Auslösezeiten für die Aktivitäten berechnet. Danach werden ihnen in Anbetracht der bestehenden Beschränkungen, Zeitschranken und zeitlichen Reserven Ressourcen zugeteilt. Falls sie für die Ablaufplanung ausreichend sind, betrachten wir die berechneten durchführbaren Ablaufszenarien als „gut genug“. Da die Ablaufszenarien im Prinzip veränderbar sind, es aber passieren kann, dass die Aufnahme einer neuen Aktivität ein Szenarium undurchführbar macht, so werden solche Aktivitäten nur dann ausgelöst, wenn sie den damit verbundenen Abbruch und die Änderung des Szenariums voraussetzen, was dessen Neuberechnung zur Folge hat. Wir kennzeichnen eine Aktivität mit den ihr anhaftenden Ressourcen- und Präzedenzeinschränkungen als Ai (dur, r, p), wobei dur ihre Ausführungszeit, r ihren Ressourcenbedarf und p ihre Präzedenzeinschränkungen angibt. Da die Aktivitäten in ein Ablaufszenarium eingeordnet sind, werden für jede Aktivität auch ihre Zeitschranken verwaltet, die durch die Attribute es (früheste Startzeit), e f (früheste Endzeit), ls (späteste Startzeit) und l f (späteste Endzeit) dargestellt werden. Das aus der Ablaufplanung resultierende Ablaufszenarium kennzeichnen wir mit S. Der JIT-Ablaufplanungsalgorithmus besteht aus zwei Phasen. Die erste Phase (Algorithmus 1) dient zur Ablaufplanung und die zweite (Alg. 3) zur Ressourcenzuteilung. Während der Ablaufplanung werden den Aktivitäten anhand ihrer Ausführungszeiten Zeitschranken zugeordnet. Während der Ressourcenzuteilung werden Ressourcenkonflikte identifiziert und Start-/Endzeiten der Aktivitäten je nach Bedarf und Möglichkeiten verschoben, um Ressourcenverfügbarkeit während der Ausführung zu gewährleisten. Dazu dient Alg. 2, durch den Ressourcen reserviert werden. Den eigentlichen, hier vorgeschlagenen JIT-Zuteilungsalgorithmus für Echtzeitsysteme geben wir in Form eines Flussdiagrams an (Abb. 1), das die Hauptausführungsschleife darstellt. Zuerst werden die Aktivitäten zeitlich eingeordnet. Danach werden die Ressourcen zugeteilt, was ein zeitgerechtes Ablaufszenarium zur Folge hat. Jede der zwei Phasen kann auch in einer Fehlanzeige resultieren, sofern die Ablaufplanung bzw. Ressourcenzuteilung in Anbetracht der angegebenen Einschränkungen nicht erfolgreich abgeschlossen werden konnte. Dann sind Maßnahmen notwendig, die aber meistens einen manuellen Eingriff in die Aktivitätenverwaltung erfordern. Daher werden sie hier nicht näher betrachtet. Einer erfolgreichen Ablaufplanung folgt die Durchführung des erstellten Szenariums, die im Ausnahmfall unterbrochen werden kann, um eine Aktivitätenänderung durchzuführen (ggf. um eine alternative Ausführung zu erzielen). Da diese (wie die früher erwähnte Korrektur im Falle eines undurchführbaren Ablaufszenariums) meistens ebenfalls manuell gesteuert werden muss, werden auch hier keine Details darüber angegeben. Jede automatische Veränderung des Ablaufszenariums würde eine Heuristik voraussetzen, die seine Ausführungszeit unbestimmbar machen könnte. Daher ziehen wir es vor, solche Änderungen manuell und statisch auszufüh-

Methoden der Logistik, Netzplantechnik und Echtzeit

Algorithmus 1 Ablaufplanung(tres ) S[1].es ← 0; for i = 1 to S.size() do max ← 0; for j = 1 to s[i].p.size() do if s[s[i].p[ j]].es + s[s[i].p[ j]].dur > max then max = s[s[i].p[ j]].es + s[s[i].p[ j]].dur; end if end for S(i).es ← max; S[i].e f ← max + S[i].dur; end for S[S.size()].l f ← S[S.size()].e f ; for j = S.size() downto 1 do if S[ j].l f = 0 then S[ j].l f ← S[S.size()].l f ; S[ j].ls = s[ j].l f − s[ j].dur; end if for i = 1 to S[ j].p.size() do if (S[S[ j].p[i]].l f = 0) or (S[S[ j].p[i]].l f > S[ j].ls) then S[S[ j].p[i]].l f ← S[ j].ls; end if end for end for if S[S.size()].l f > tres then {Nicht ausführbar!} end if

Algorithmus 2 Reserve(t, r, st, f t) for i = 1 to S.size() do if i <> t then if (st ≥ s[i].es) and ( f t ≤ s[i].l f ) then for j = 1 to S[i].r.size() do if s[i].r[ j] = r then if s[i].dur + s[t].dur > ( f t − st) then {Nicht ausführbar!} else {S[i].es, S[i].l f and S[t].es, S[t].l f entsprechend anpassen.} end if end if end for end if end if end for

53

54

R. Gumzej, M. Lipiˇcnik

Algorithmus 3 Ressourcenzuteilung() for i = 1 to S.size() do for j = 1 to S[i].r.size() do if NOT reserve(i, s[i].r[ j], s[i].es, s[i].l f )) then {Nicht ausführbar!} end if end for end for

Abb. 1: JIT Ablaufplanungsalgorithmus

Methoden der Logistik, Netzplantechnik und Echtzeit

55

ren, um Einfachheit und zeitlichen Determinismus der Ablaufplanung und -ausführung beizubehalten.

4 Diskussion des Ansatzes Problematisch bei Ressourcen ist abgesehen von ihrer begrenzten Anzahl auch ihre Diversität. Vielleicht wäre ihre Vereinheitlichung möglich, da letztere keine große Einschränkung bedeuten würde; denn da in den meisten Fällen Prozesse (eingebettete) Rechnersysteme während ihrer Ausführung für sich reservieren, sollten sie auch über alle deren (daran angeschlossenen) Ressourcen frei verfügen können. Hiermit wäre die nötige Voraussetzung einheitlicher Ressourcenverwaltung im Rahmen der Prozesseinheiten (Aktivitäten) geschaffen. Die zweite Phase würde sich damit erübrigen, was die Ablaufplanung beschleunigen und vereinfachen würde. Demzufolge wäre ein Rechnersystem das einzige Betriebsmittel, das als Gesamtheit aller Rechen-, Sensor- und Aktoreinheiten einer Task während ihrer Ausführung zur Verfügung zu stellen wäre. Da die Prinzipien JIT und JIS denen der Echtzeitablaufplanung unter Ressourcenbeschränkungen gleichen, ist es möglich, zur Ablaufplanung und Zuordnung von Ressourcen die Verfahren CPM und CCPM (siehe Abb. 1 und 3) statt ähnlicher zeitgesteuerter Ablaufplanungsalgorithmen (wzb. EDF und LLF) zu benutzen. Dabei ist zu erwähnen, dass diese Verfahren eine Gesamtablaufzeit für alle Aktivitäten eines Prozessablaufs vorsehen. Obwohl die Ablaufplanung mit Ausführungszeiten individueller Aktivitäten (Tasks) operiert, bezieht sich demnach die Zeitplanung auf die Prozessgesamtzeit, binnen derer diese Aktivitäten ausgeführt werden. Das ist in der Prozessindustrie oft der Fall, wobei für Echtzeitsysteme davon ausgegangen wird, dass auch individuelle Aktivitäten (Tasks) ihre Fristen einhalten müssen und deswegen separat geprüft werden sollten. Es wäre einfach, aber von der Ablaufplanung her suboptimal, diese Fristenverwaltung auch für Aktivitäten einzuführen. Dann würde sich die Zeitplanung auf Fristen konzentrieren, wobei die Differenz zwischen Frist und Ausführungszeit als Reserve verwaltet würde. Für die Ressourcenreservierung könnte man diese zusätzliche Zeitreserve sehr wohl nutzen, um die Aktivitäten, die auf dieselben Ressourcen zugreifen, dementsprechend einzuordnen. Die Zeitschranken könnte man wie bei CCPM anhand der Faustregel der doppelten Ausführungszeit bzw. -frist bestimmen, um den gleichen Effekt zu erreichen. Eine weitere Möglichkeit der JIT/JIS-inspirierten Ablaufplanung ergibt sich für Aktivitäten, die als Zustandsdiagramme dargestellt werden können, da diese den PERTDiagrammen sehr ähnlich sind, die bei CPM-Analyse breiten Einsatz finden. Die Zustände würden dann als Aktivitäten verwaltet und deren Präzedenzen durch die Zustandsübergänge definiert, wobei vollständige Ausführung innerhalb der Zustände als einzige Voraussetzung für Zustandsübergange zu betrachten wäre. Die Gesamtausführungszeit einer Task würde in diesem Fall der Ausführungszeit des Ablaufs im Zustandsdiagramm gleichen. Das würde wiederum die Task-Verwaltung mit gewohnten zeitgesteuerten Ablaufplanungsalgorithmen (wzb. EDF und LLF) ermöglichen, was vor allem in harten Echtzeitumgebungen nützlich wäre, da Zeitreserven dann auf Zustandsebene verwaltet werden könnten.

56

R. Gumzej, M. Lipiˇcnik

5 Schlussbemerkungen Es hat sich gezeigt, dass die Konzepte der Ablaufplanung in der Logistik und Netzplantechnik einerseits und für Echtzeitsysteme andererseits durchaus gemeinsame Fundamente haben. Deswegen konnte die JIT-Ablaufplanungsstrategie problemlos in den Bereich der Echtzeitsysteme übertragen werden. Voraussetzung zu ihrer weiteren Anwendung für die Zuteilbarkeitsanalyse ist die genaue Kenntnis der Prozessabläufe, d. h. der Aktivitäten und Ressourcenanforderungen. Für störungsfreien Betrieb in harten Echtzeitumgebungen müssen die Zeitreserven der Aktivitäten genau überprüft und Strategien der Ausfallsicherheitsgerichtetheit definiert werden. Dabei ist hervorzuheben, dass Planung nach dem JIT-Verfahren die Möglichkeit von Ausfällen wegen Undurchführbarkeit minimiert. Da zugleich die Planung des Ressourceneinsatzes in polynomialer Zeit stattfindet, stellt sich dieses Ablaufplanungsverfahren als durchaus sinnvoll heraus und könnte somit vor allem in der Prozessindustrie breite Anwendung finden.

Literaturverzeichnis 1. Audsley N, Burns A: Real-Time System Scheduling. ESPRIT BRA Project (3092), Predictably Dependable Computer Systems, Vol. 2, Ch. 2, Part II, 2004. 2. Kerzner H: Project Management: A Systems Approach to Planning, Scheduling, and Controlling. 8. Aufl., 2003, ISBN 0-471-22577-0. 3. Leach LP: Critical Chain Project Management. Artech House, 2000, ISBN 1-58053-074-5. 4. Schonberger RJ: Japanese Manufacturing Techniques: Nine Hidden Lessons in Simplicity. Free Press, 1982, ISBN 0029291003. 5. Shingo S: A Study of the Toyota Production System: From an Industrial Engineering Viewpoint (Produce What Is Needed, When It’s Needed). Productivity Press, 1989, ISBN 0915299178.

Bienen-inspiriertes Straßenverkehrsrouting Sebastian Senge, Sebastian Lehnhoff und Anca M. Lazarescu TU Dortmund, Fakultät für Informatik, Lehrstuhl III, August-Schmidt-Str. 12, 44227 Dortmund        

Zusammenfassung. Verkehrsstaus verursachen hohe Kosten – in ökonomischer als auch in ökologischer Hinsicht. Verkehrsstaus können als verteilte und dynamische Probleme betrachtet werden, da keine zentrale Regelinstanz, sondern im Gegenteil jeder Fahrer (im Wesentlichen unabhängig voneinander) über den Beginn und die Strecke der Fahrt selbst entscheidet. Wir argumentieren, dass ein adäquater Lösungsansatz zur Stauvermeidung (sowie zur Minimierung von Reisezeiten und Umweltbelastung) auf globale Informationen verzichten muss, um auf dynamische Änderungen des Verkehrsaufkommen in Echtzeit reagieren zu können, in Straßenverkehrsnetzen realistischer Größe. In diesem Beitrag wird das verteilte Routingsystem BeeJamA in seiner Weiterentwicklung als Vehicleto-Infrastructure (V2I) Architektur beschrieben, zur inzwischen erfolgenden realitätsnahen Evaluierung im MATSim Simulator.

1 Einleitung Europaweit entstanden im Jahr 2000 Schäden in Höhe von ca. 270 Milliarden Euro durch Verkehrsstaus [1]. Die bisherigen Modelle zu deren Reduzierung bzw. Vermeidung basieren jedoch entweder auf Entscheidungsfindung aus globaler Information bzw. Voraussagen oder auf unkoordinierten autonomen Entscheidungen der einzelnen Verkehrsteilnehmer, die Voraussagen aus ebensolchen Voraussagen benutzen. Schon die Praxis zeigt, dass Voraussagen von ihrer Erstellung bis zu ihrer Übermittlung so lange brauchen, dass sie regelmäßig für Entscheidungen in der inzwischen eingetretenen Situation (die ihnen noch nicht bekannt ist!) nicht mehr nutzbar oder sogar kontraproduktiv sind. Anders ausgedrückt muss jede Routingentscheidung auch dann noch, wenn sie getroffen wird, bzgl. der gegebenen Verkehrslage adäquat („richtig“) sein, gleichzeitig im Kontext der Verkehrsteilnehmer, aber auch rechtzeitig vor jeder Einmündung, an diese übermittelt werden. Dies sind zwei sehr harte Randbedingungen für z.T. dynamische Deadlines, die anderweitig noch nie für größere Verkehrssysteme erfüllt wurden (vgl. dazu die Besprechung in [2]), jedoch im Zentrum unseres eigenen BeeJamA Ansatzes stehen. Es versteht sich nach Obigem von selbst, dass ein solches Ziel nur unter der Annahme dezentraler Kontrolle angestrebt werden kann. Für ein eingeschränktes Modell hatten wir schon vorher [2] ein auf Schwarmintelligenz basierendes Routingsystem beschrieben, nach dem Staus vermieden, durchschnittliche Reisezeiten minimiert werden können. Dieser Ansatz ist beliebig skalierbar, weil die jeweils durch die dezentralen Agenten zu verwaltende Information stets lokal überschaubar bleibt. Da die Echtzeitbedingungen aus den realen Verkehrsverhältnissen stammen

58

S. Senge, S. Lehnhoff, A.M. Lazarescu

(z.B. von der tatsächlichen Geschwindigkeit der Fahrzeuge abhängen), wächst die Güte der Systemevaluation mit der steigenden Nähe zum realen Anwendungssystem. Die letztgültige Echtzeit-Bewertung – zumal in verteilten Systemen – kann erst im realen System erfolgen, weil die obigen Randbedingungen qualitativer Natur sind. In diesem Papier beschreiben wir eine für große reale Verkehrssysteme wesentliche Erweiterung des BeeJamA Modells, bei der es gleichzeitig gelungen ist, den Informationsaufwand im gleichen Umfang wie vorher zu halten. Für seine Evaluation wird gerade die Implementation in den äußerst leistungsfähigen MATSim Simulator [3] fertiggestellt. Dies ist ein wesentlicher Entwicklungsschritt für BeeJamA, als Teil einer mehrstufigen (s.o.) inkrementellen Prozedur, die für verteilte Realzeitsysteme notwendig und typisch ist. Aufbau der Arbeit. In Abschnitt 2 wird eine verteilte Architektur vorgeschlagen, welche die Grundlage für das vorgeschlagene V2I-Routingsystem bildet. In Abschnitt 3 wird der bisher entwickelte Routingalgorithmus des BeeJamA Systems kurz skizziert, sowie dessen Erweiterung vorgestellt.

2 Vehicle-to-Infrastructure-Architektur Die Modellerweiterung des BeeJamA Systems [2] zum Zwecke größerer Praxisnähe betrifft die Kommunikationsinfrastruktur zwischen Fahrzeugen und dezentral koordinierten Routingagenten (Navigatoren) sowie den Wegfall einschränkender Annahmen über die Straßentopologie. (Letzteres wird in Abschnitt 3 behandelt.) Obwohl unabhängig von den Routingverfahren, wird die Kommunikationsinfrastruktur für eine realitätsnahe Simulation benötigt. Wir haben mit einem Vehicle-to-Infrastructure (V2I) Ansatz eine im Vergleich zu anderen Zielführungsverfahren sehr kostengünstige Methode gewählt. Sie wurde am Lehrstuhl prototypisch mittels IEEE 802.11 realisiert und programmiert für die dezentrale Kommunikation in BeeJamA, zwischen den verteilten Navigatoren sowie zwischen diesen und den jeweils von ihnen lokal geführten Fahrzeugen gem. BeeJamA. Es wurden nur handelsübliche OpenMoko Smartphones (     ) und (für die Navigatoren) Standard-PCs benutzt. Auf dieser Grundlage werden für jedes Fahrzeug und sein jeweiliges Ziel möglichst in seiner gegenwärtigen Position, jedoch spätestens zu seiner dynamischen Deadline, Routingentscheidungen empfangen und umgesetzt. Abb. 1 zeigt diese Zusammenhänge in leicht vereinfachter Weise, wobei die unterschiedlichen Fahrzeugumgebungen (Schlange, Gegen-, Querverkehr) speziell die Komplexität der Geschwindigkeitsabhängigkeit andeuten können. Die Echtzeitbedingung des vorgeschlagenen Systems ist demnach dadurch gegeben, dass die Routingempfehlung vor dem Erreichen des Fahrzeuges der nächsten Kreuzung geliefert werden muss. Die weiteren technischen Details sprengen den Rahmen dieser Darstellung.

3 (Erweiterter) BeeJamA Algorithmus Das BeeJamA Projekt basiert auf langjährigen intensiven F&E-Arbeiten am Lehrstuhl über effiziente, adaptive, fehlertolerante, sichere Routingverfahren in großen Computernetzen. Das Resultat waren die sog. BeeHive und BeeAdhoc-Algorithmen [4]. Diese bienen-basierten, schwarm-intelligenten Verfahren wurden in mehreren Teilschritten

Bienen-inspiriertes Straßenverkehrsrouting

59

getNextHop()

Ziel 1

X

A

B

C Ziel 2

Y E

Deadline Aktuelle Position

Abb. 1: Dynamische Deadline, zu dem die Routingempfehlung vorliegen muss.

für den Einsatz im Verkehrsrouting adaptiert. Unsere Einführung ist aus Platzgründen kursorisch, mehr technische Details sind in [2] zu finden. Sie geschieht nur als Vorbereitung der hier anstehenden Erweiterung der in [2] dargestellten ersten Variante des BeeJamA Algorithmus. Der BeeJamA Algorithmus (die alte als auch die neue Variante) ist als Mehrschichtenansatz entworfen (siehe Abb. 2).

Abb. 2: BeeJamA Schichtenmodell.

60

S. Senge, S. Lehnhoff, A.M. Lazarescu

Die sogenannte Bereichsschicht (area layer) entspricht einem Graphen, bei dem Knoten Kreuzungen und Straßen Kanten entsprechen, d.h. diese Schicht korrespondiert mit dem gegebenen Straßennetz. Ein Bereich entspricht dem Verantwortungsbereich eines Navigators. Die Bereiche sind gerade so groß festgelegt, dass die Steuerungsaufgaben jedes Navigators unter den zeitlichen Randbedingungen erfüllbar sind (siehe 2). (Das Layout geschieht off-line.) Die Steuerung über Bereichsgrenzen hinweg geschieht durch Koordination der Navigatoren auf der zweiten Schicht, der sog. Netzschicht (net layer), durch die jeder Navigator Routinginformationen für Fahrzeuge gewinnt bzw. zu deren Gewinnung beiträgt. Da Fahrzeuge aber typischerweise weitere Strecken zurücklegen und somit mehrere Bereiche durchqueren, um an ihr Ziel zu gelangen, werden auf der Netzschicht die Informationen zum Routing zwischen den Bereichen verwaltet. Nachdem zunächst in [2] nur ein Übergang zwischen Bereichen angenommen wurde, werden nun alle Rand-/Übergangskanten betrachtet. (Dabei werden Bereichsgrenzen so gezogen, dass jeder Straßenabschnitt ganz in gerade einem der Bereiche verläuft.) Routingentscheidungen beruhen auf der Belastung der Straßenabschnitte durch Fahrzeuge. Diese ist durch Dichte und Geschwindigkeit der einzelnen Fahrzeuge bestimmt. Ihre Position wird als dem jeweiligen Navigator bekannt vorausgesetzt (bei SmartPhones etwa über GPS bestimmt und periodisch übermittelt). In [2] haben wir zur Steuerung aus intensiven empirischen Studien Abhängigkeiten zwischen Fahrzeugdichte (ρ ) und durchschnittlicher Fahrzeuggeschwindigkeit (v) für unterschiedliche Straßentypen berücksichtigt (Abb. 3(a)). Erkennbar sind die drei Phasen Staufrei, Übergang, Stau. Bei bekannter „hoher“ Belastung eines Straßenabschnitts (gem. Abb. 3(a)) wären also zur Stauvermeidung zugunsten dieses Abschnitts geeignete Routing-Maßnahmen zu ergreifen.

(a) Empirische Abhängigkeit für eine vierspurige Autobahn.

(b) Approximativer Zusammenhang

Abb. 3: Zusammenhang zwischen Fahrzeugdichte (ρ ) und durchschnittlicher Fahrzeuggeschwindigkeit (v).

Diese für alle Straßentypen charakteristischen Zusammenhänge haben wir graphisch approximiert (Abb. 3(b)) und die gewonnen Kurven unter Zuhilfenahme von vier Para-

Bienen-inspiriertes Straßenverkehrsrouting

61

metern A, B, α , β funktional festgeschrieben: ⎧ A−vmax 2 ⎪ ⎪ ⎨ α 2 ρ + vmax (ρ −α )(B−A) +A vedge = β −α ⎪ 4 ⎪ β ⎩ 4B ρ

falls 0 < ρ ≤ α (Staufrei), falls α < ρ ≤ β (Übergang),

(1)

falls ρ > β (Stau).

Die Kosten oder das Gewicht einer Kante werden dann wie folgt berechnet: cedge =

ledge , vedge

(2)

wobei ledge die Länge der Kante bezeichnet. So entsprechen die Kosten einer Kante approximierten Reisezeiten über die korrespondierende Straße.

3.1 Routingtabellen der Bereichsschicht Abbildung 4 zeigt das Beispiel eines Straßennetzes, welches in die drei Bereiche B,C und D eingeteilt ist. Wie vorstehend ausgeführt entspricht ein Bereich auf der Bereichsschicht dem Verantwortungsbereich eines Navigators (nicht eingezeichnet). Diese Bereiche können als konstant angenommen werden, da das Layout des Straßennetzes sich höchstens langfristig ändert (temporäre Nichtbefahrbarkeit lässt sich durch hohe Kosten modellieren). Daher werden innerhalb eines Bereichs alle Wege zwischen den Knoten als bekannt angenommen, und die Größe der Routingtabellen ändert sich nicht. Die (dynamischen) Kosten zwischen diesen Knoten werden in der sogenannten Intra Foraging Zone (IFZarea ) Routingtabelle pro Knoten verwaltet. Die Bezeichnung Foraging Zone leitet sich von Gegebenheiten des BeeHive Algorithmus [4] ab und sei auf der Bereichsschicht synonym mit der des Bereichs verwendet (vgl. auch [2]). Für jeden Knoten eines Bereichs koinzidiert die Foraging Zone mit dem Bereich. Bei n Knoten in einer Foraging Zone, existieren n IFZarea Tabellen statischer (aber ggf. unterschiedlicher) Größe, die von dem zugehörigen Navigator verwaltet werden. In der Tabelle werden die Kosten zu jedem anderen Knoten in der Foraging Zone über einen der Nachbarknoten gespeichert, der Aufbau unterscheidet sich also von dem anderer Routingalgorithmen. Die IFZarea Tabelle des Knoten x hat die Größe |Nx | × |Dx |, wobei Nx die Menge der direkten Nachbarknoten von x und Dx die Menge der Knoten in der Foraging Zone von x ist, Nx ∈ Dx . Die Einträge in der Tabelle repräsentieren die Kosten von Knoten x zu einem Knoten d ⊆ Dx über den nächsten Nachbarknoten n ∈ Nx zu reisen. Mit diesen Informationen lassen sich Fahrzeuge innerhalb der Foraging Zone routen. Der Navigator wählt probabilistisch, aber gewichtet nach den Kosten einen Nachbarkonten des aktuellen Knotens (d.h. an dem sich das Fahrzeug aktuell befindet) aus, bis das Fahrzeug das Ziel erreicht. Um Routingentscheidungen über Bereichsgrenzen hinweg zu ermöglichen, wird zusätzlich in der FRMarea Tabelle auf der Bereichsschicht eine Abbildung von Knoten zu zugehörigen Bereichen vorgehalten. Die Tabelle ist in der Größe als auch von den Einträgen her statisch und hat bei N Knoten im gesamten Graphen die Größe 2 N.

62

S. Senge, S. Lehnhoff, A.M. Lazarescu

Abb. 4: Bereichsschicht

3.2 Routingtabellen der Netzschicht Die Netzschicht dient dem Routing über große Distanzen, d.h. wenn Start und Ziel nicht in demselben Bereich liegen. Die Idee des zugrunde liegenden BeeHive Algorithmus ist es, die zu routenden Objekte (hier: Fahrzeuge) Knoten für Knoten in die „grobe Richtung“ des Ziel zu senden. Ist das Fahrzeug dann im Zielgebiet, wird mittels präziser Informationen geroutet. Der Graph der Netzschicht besteht aus den Randknoten der einzelnen Bereiche und einer vollständigen Kantenmenge auf den Randknoten eines Bereichs. Abb. 5 zeigt ein Beispiel. Eine Kante auf der Netzschicht entspricht zu jedem Zeitpunkt einem Pfad auf der Bereichsschicht. Der exakte Pfad wird Schritt für Schritt, während das Fahrzeug fährt, gemäß den dann aktuellen Kosten aus den Routingtabellen bestimmt (siehe Abschnitt 3.4). Die Grundlage für das Aktualisieren der Tabellen auf der Netzschicht ist der BeeHive Algorithmus. Auf der Netzschicht existiert eine Foraging Zone für jeden Knoten, welcher nicht deckungsgleich mit der Foraging Zone eines Knotens auf Bereichsschicht sein muss. Die Foraging Zone eines Knotens auf der Netzschicht ist die Menge der Knoten, die durch eine vorgegebene Anzahl von Hops erreichbar ist. Die Foraging Zone auf der Netzschicht modelliert ebenfalls den „Nahbereich“ eines Knotens, über den präzise Informationen vorhanden sind. Zusätzlich existiert auf der Netzschicht eine Einteilung in sog. Foraging Regions, welche das Zielgebiet modellieren. Es handelt sich dabei um eine fixe Partitionierung der Foraging Zones auf der Bereichsschicht. Eine Foraging Region wird durch einen repräsentativen Knoten repräsentiert, in dessen Richtung geroutet wird, wenn ein Fahrzeug aus einer anderen Foraging Zone der Netzschicht des aktuellen Knotens kommt. Auf der Netzschicht werden dazu drei Routingtabellen verwaltet: Intra Foraging Region (IFRnet ), Intra Foraging Zone (IFZnet ) und Foraging Region Membership (FRMnet ) (vgl. auch [2]). (Die Verwaltung wird von den Navigatoren übernommen, es bedarf keiner eigenen Hardware.) Die IFZnet Tabelle ist analog zur IFZarea Tabelle auf der Bereichsschicht aufgebaut: sie enthält die Kosten der Pfade des jeweiligen Knotens zu allen Knoten der jeweiligen Foraging Zone auf der Netzschicht über alle direkten Nachbarknoten. Die Größe der Tabelle des Knotens x

Bienen-inspiriertes Straßenverkehrsrouting

(a) Foraging Regions

63

(b) Kantenmenge

Abb. 5: Netzschicht

beträgt |Nx | × |Zx |, wobei Nx die Menge der direkten Nachbarn ist und Zx die Menge der Knoten der Foraging Zone des Knotens auf der Netzschicht. Allerdings haben die IFZnet Tabellen viele Einträge gemeinsam, wie sie schon für die involvierten IFZarea erhoben wurden. Sie können also über statische Links davon Gebrauch machen, was den Mehraufwand gegenüber dem einfacheren Modell [2] sehr in Grenzen hält. Die statische und für jeden Knoten gleiche FRMnet Tabelle bildet jeden Knoten der Netzschicht auf die zugehörige Foraging Region ab (Größe: 2 N, bei N Knoten auf der Netzschicht). Die IFRnet Tabelle speichert die (Next-Hop-)Kosten zu den repräsentativen Knoten außerhalb der aktuellen Foraging Region über alle direkten Netzschicht-Nachbarknoten. Die Größe beträgt |Nx | × |R|, wobei Nx die Menge der direkten Nachbarn des Knotens x ist und R die Menge der repräsentativen Knoten der Netzschicht. Anhand dieser Informationen können Fahrzeuge, wie in Abschnitt 3.4 gezeigt wird, auf der Netzschicht geroutet werden. 3.3 Aktualisieren der Routingtabellen Das stetige Aktualisieren der Routingtabellen wird wie in BeeHive durchgeführt. Es existieren dabei zwei Typen von Agenten: Short Distance Bee Agents und Long Distance Bee Agents. Eine umfassende Beschreibung des gesamten Ablaufes entnehme man [4], hier sei nur eine gekürzte informelle Beschreibung gegeben: 1. Jeder nichtrepräsentative Knoten sendet periodisch Kopien einer Short Distance Bee Agent an alle direkten Nachbarknoten mittels Broadcast (Flooding). 2. Erreicht eine Kopie solch eines Agenten einen Knoten, dann werden zunächst die jeweiligen Tabelleneinträge aktualisiert. Danach werden Kopien wiederum an alle direkten Nachbarn weitergesendet (mit Ausnahme des Nachbarn, von dem der

64

S. Senge, S. Lehnhoff, A.M. Lazarescu

Agent kam). Dieser Prozess wird wiederholt, bis das Hop Limit erreicht ist oder eine Kopie dieses Agenten bereits an diesem Knoten empfangen wurde. 3. Repräsentative Knoten senden Long Distance Bee Agents nach dem gleichen Prinzip, mit dem Unterschied, dass das Hop Limit größer ist. Insgesamt erhält dadurch jeder Knoten stets aktuelle Kosteninformationen (abhängig von der sehr kurzen Flooding-Periode und dem Layout des Graphen) über die Reisezeiten zu den Knoten in der eigenen Foraging Zone und zu den repräsentativen Knoten des Netzes. 3.4 Routingentscheidungen Angenommen ein Fahrzeug befindet sich an Knoten x in Bereich X mit dem Zielknoten y in Bereich Y . Es können dann drei mögliche Fälle beim Routen von Fahrzeugen auftreten: 1. Der Zielknoten y ist in der Tabelle des aktuellen Bereichs enthalten und liegt somit in Bereich X (X = Y ). 2. Der Zielknoten y liegt nicht im aktuellen Bereich X (da kein Eintrag in der aktuellen Tabelle), allerdings liegt der Zielbereich Y in der Netzschicht-Foraging Zone des Knotens X, d.h. jeder Randknoten von Y ist in den Tabellen der Randknoten des aktuellen Bereichs X enthalten. 3. Die ersten beiden Fälle treffen nicht zu, d.h. der Zielknoten ist weder in der Tabelle des Bereichs X enthalten, noch ist der Zielbereich Y in den Tabellen der Randknoten des aktuellen Bereichs enthalten. Folglich liegt der Zielknoten y außerhalb des aktuellen Bereichs X und der Zielbereich liegt außerhalb der Netzschicht Foraging Zone des aktuellen Bereichs X . Diese drei Fälle spiegeln Szenarien wieder, in denen der Zielknoten y weiter und weiter vom aktuellen Bereich X entfernt ist. Im ersten Fall reichen die Informationen der Bereichsschicht. Dazu wird der nächste Knoten (also die Routingempfehlung) probabilistisch gemäß den normalisierten Kosten der Next-Hop-Einträge in der Tabelle des aktuellen Bereichs X bestimmt. Im zweiten Fall akkumulieren sich die Kosten über die Bereichs- und Netzschicht, sie setzen sich aus drei Teile zusammen: – Die Kosten vom aktuellen Knoten x zu einem Randknoten des aktuellen Bereichs X. – Die Kosten von diesem Randknoten zu einem Randknoten des Zielbereichs Y auf der Netzschicht. – Die Kosten von einem Randknoten von Zielbereich Y zu dem Zielknoten Y . Seien BX und BY die Mengen der Randknoten der Bereich X bzw. Y , dann wird der nächste Knoten probabilistisch (gewichtet gemäß den kumulierten Kosten) unter O(|BX | × |BY |) möglichen Routen gewählt. Abb. 6(a) illustriert die möglichen Routen. Die Kante e korrespondiert zu dem Eintrag in der Tabelle von Randknoten BX,1 mit den geringsten Kosten von allen möglichen Routen von BX,1 zu BY,m−1 . Da eine Kante auf der Netzschicht einem Pfad auf der Bereichsschicht entspricht, ist somit auch der nächste Knoten bekannt, der als Routingempfehlung verwendet wird.

Bienen-inspiriertes Straßenverkehrsrouting

(a) Fall 2

65

(b) Fall 3

Abb. 6: Mögliche Routen bei der Routingentscheidung.

Im dritten Fall bestehen die kumulierten Kosten aus zwei Teilen: 1. Die Kosten vom aktuellen Knoten x zu einem Randknoten des aktuellen Bereichs X. 2. Die Kosten von diesem Randknoten zu dem repräsentativen Knoten RY der Foraging Region des Zielbereichs Y . In Analogie zu dem BeeHive Algorithmus besteht die Grundidee in diesem dritten Fall darin, das Fahrzeug zunächst in die grobe Richtung des Zielgebietes (modelliert durch die Foraging Region) des Zielbereiches Y zu routen, bis das Fahrzeug dem Ziel nah genug kommt, dass Y in der IFZnet Tabelle eines besuchten Knotens enthalten ist. Abb. 6(b) illustriert die möglichen Kombinationen der Routen zu dem repräsentativen Knoten der Foraging Region des Zielbereichs Y . Sei BX die Menge der Randknoten im Bereich X, dann wird der Next-Hop-Knoten probabilistisch (gewichtet gemäß den kumulierten Kosten) unter O(BX ) möglichen Routen bestimmt. In der Abb. 6(b) entspricht die Kante f dem Eintrag in der IFRnet Tabelle des Knotens BX,1 mit den geringsten Kosten von allen Routen von BX,1 nach RY . Wiederum ist damit ein Pfad auf der Bereichsschicht gegeben (siehe Fall 2). Analog zu BeeHive wird im BeeJamA Algorithmus eine Route nur dann ausgewählt, falls die Kosten einen Grenzwert nicht überschreiten. So wird verhindert, dass zu lange Umwege gewählt werden. Obwohl nicht alle Fahrzeuge stets den „besten Weg“ nehmen, ist aber dank der Schwarmintelligenz der Routingansatz BeeHive allen anderen bekannten überlegen [4]. Davon sollte auch im erweiterten Fall BeeJamA profitieren. Schließlich ist, wie in Abschnitt 3.2 angedeutet, die Berücksichtigung mehrfacher Bereichsübergänge mit der Vergrößerung der Tabellen, aber auf der Netzebene auch mit weniger Kommunikationsaufwand verbunden, soweit nämlich die Netzinformation schon auf der Bereichsebene zur Verfügung steht.

4 Zusammenfassung und Ausblick In diesem Papier wurde in einem erweiterten und kostengünstigen Infrastrukturmodell (V2I) und für allgemeine Straßentopologien der erweiterte verteilte und adaptive

66

S. Senge, S. Lehnhoff, A.M. Lazarescu

Straßenverkehrs-Routingalgorithmus BeeJamA vorgestellt. Es konnte auf kostengünstige Hardware zurückgegriffen werden. Da alle Entscheidungen von dezentralen Navigatoren immer aus überschaubaren Informationen gewonnen werden, in Kommunikationen dieser Agenten nur mit Nachbarn (Bienenintelligenz!), ist der Ansatz beliebig skalierbar, auch bzgl. des nicht einmal linear steigenden Kommunikationsaufwandes. Im vereinfachten Modell [2] war in extensiver Simulation mit Verkehrsdaten aus dem Ruhrgebiet sichergestellt worden, dass die dynamischen Deadlines eingehalten wurden (s. Abschnitt 1), das Hauptanliegen des BeeJamA Projekts. Das erweiterte Modell ist inzwischen für den MATSim Simulator [3] implementiert worden. Sollten sich die bisherigen Tendenzen weiter bestätigen, so sind bei Anwendung von BeeJamA in realen Verkehrssystemen gleichzeitig Stauvoraussagen obsolet geworden, da Staus vermieden und Fahrtzeiten minimiert werden.

Literaturverzeichnis 1. W. Rothengatter. External costs of transport (2004). Online verfügbar unter:               – aufgerufen am 29.07.2009. 2. H. F. Wedde, S. Lehnhoff, B. van Bonn, Z. Bay, S. Becker, S. Böttcher, C. Brunner, A. Büscher, T. Fürst, A.M. Lazarescu, E. Rotaru, S. Senge, B. Steinbach, F. Yilmaz und T. Zimmermann. Highly Dynamic and Adaptive Traffic Congestion Avoidance in Real-Time Inspired by Honey Bee Behavior. Informatik Aktuell, PEARL 2007, Springer, 2007. 3. Multi Agent Transportation Simulation Toolkit, TU Berlin, Lehrstuhl für Verkehrssystemplanung und Verkehrstelematik,   . 4. M. Farooq. Bee-Inspired Protocol Engineering – From Nature to Networks. Springer, Berlin, 2009. 5. T. Ernst. The Information Technology Era of the Vehicular Industry. The ACM SIGCOMM Computer Communication Review, 2006. 6. B.S. Kerner, C. Demir, R.G. Herrtwich, S.L. Klenov, H. Rehborn, M. Aleksic und A. Haug.Traffic State Detection with Floating Car Data in Road Networks. IEEE Intelligent Transportation Systems, 2005.

Schichtübergreifende Früherkennung von Verbindungsausfällen in drahtlosen Mesh-Netzwerken Timo Lindhorst Institut für Verteilte Systeme Otto-von-Guericke-Universität Magdeburg     

Zusammenfassung. Drahtlose Mesh-Netzwerke (WMNs) bilden aufgrund ihrer Selbstorganisation ein flexibles Kommunikationssystem. Bei der Erkennung einzelner Verbindungsausfälle, die bei der Integration mobiler Teilnehmer unvermeidbar sind, ist bei aktuellen Routingprotokollen die Kommunikation jedoch für mehrere Sekunden unterbrochen. In dieser Arbeit wird gezeigt, wie durch Nutzung von Informationen aus der MAC-Schicht ein Ausfall frühzeitig erkannt und dadurch die Anzahl der Paketverluste von mehreren Hundert auf maximal vier reduziert werden kann. Hierdurch wird die Zuverlässigkeit und Verfügbarkeit von WMNs erhöht und ihr Einsatz für Echtzeit-Anwendungen ermöglicht.

1 Motivation Drahtlose Kommunikationssysteme haben in den letzten Jahren einen wichtigen Stellenwert erlangt. Dabei ist die kabellose Integration mobiler Teilnehmer in ein Netz die vorrangige Motivation gewesen. Weitere Vorteile gegenüber drahtgebundenen Netzen ergeben sich durch geringere Kosten und flexible Einsetzbarkeit aufgrund des geringeren Installationsaufwandes. Insbesondere gelten diese Eigenschaften für drahtlose Mesh-Netzwerke (Wireless Mesh Network, WMN). Während im herkömmlichen WLAN nach dem IEEE 802.11 Standard Access Points untereinander über ein drahtgebundenes Backbone-Netz kommunizieren, sind WMNs vollständig drahtlos aufgebaut. Die Teilnehmer bilden eine vermaschte Topologie, indem jede Station Verbindungen zu sämtlichen Nachbarn in Funkreichweite etabliert. Ein Routingprotokoll realisiert die Kommunikation zwischen zwei Stationen im Netz durch die Weiterleitung der Pakete über geeignete Pfade. Durch die Selbstorganisation, Selbstheilung und Selbstoptimierung bilden WMNs ein besonders flexibles Kommunikationssystem. Um ein möglichst großes Anwendungsfeld erschließen zu können, müssen drahtlose Netze ähnlich gute Übertragungseigenschaften bieten wie drahtgebundene Netze. Besonders die Industrie stellt hohe Anforderungen an die Zuverlässigkeit und Verfügbarkeit der Systeme. Der Einsatz bei zeitkritischen Steuerungsprozessen stellt Echtzeitanforderungen an die Kommunikation, gleichfalls die Übertragung von Sprachoder Videodaten.

68

T. Lindhorst

Die Realisierung einer zuverlässigen und echtzeitfähigen Kommunikation wird jedoch durch die Eigenschaften drahtloser Netze erschwert – die Verwendung eines geteilten Kommunikationsmediums und die Unterstützung mobiler Teilnehmer. Während in drahtgebundenen Netzen Verbindungsausfälle nur durch den Ausfall einer Komponente hervorgerufen werden, geschieht dies in drahtlosen Netzen bei Störung durch äußere Einflüsse oder wenn ein mobiler Teilnehmer den Empfangsbereich verlässt. Verbindungsausfälle sind demnach bei einer drahtlosen Kommunikation nicht zu vermeiden und müssen behandelt werden. WMNs bieten aufgrund ihrer Vermaschung meist redundante Pfade zwischen zwei Stationen. Dennoch muss der Ausfall einer Verbindung zunächst erkannt werden, damit die Kommunikation auf einem alternativen Pfad fortgesetzt werden kann. Hierzu benötigen aktuelle Routingprotokolle im Allgemeinen mehrere Sekunden. Da während dieser Zeit die Kommunikation unterbrochen ist, sind diverse Echtzeit-Anwendungen mit WMNs bisher nicht realisierbar. Das Ziel der Arbeit besteht in der Reduzierung der Ausfallzeiten und der Beschränkung von Paketverlusten durch eine schnellere Erkennung von Verbindungsausfällen. Auf diese Weise soll die Zuverlässigkeit und Verfügbarkeit von WMNs verbessert werden, wodurch ihr Einsatz für Echtzeit-Anwendungen ermöglicht wird.

2 Schichtübergreifende Ausfallerkennung Die Erkennung von Verbindungsausfällen kann als Aufgabe der Nachbarschaftssuche im Routingprotokoll eingeordnet werden. Diese wird meist mittels Beaconing realisiert: Alle Stationen senden mit einer Periode τ Beacons, die von den Nachbarn in Kommunikationsreichweite empfangen werden. Nach dem Empfang einiger Beacons gilt die Verbindung als etabliert. Der Ausfall einer Verbindung wird dadurch erkannt, dass keine Beacons mehr empfangen werden. Jedoch können auch auf relativ stabilen Verbindungen einzelne Paketverluste auftreten. Um sporadische Paketverluste von einem Verbindungsausfall zu unterscheiden, wird erst nach dem Ausbleiben von n Beacons ein Ausfall angenommen. Die Verzögerung bei der Erkennung von Verbindungsausfällen ergibt sich demnach etwa zu Δ t = n · τ . Durch Anpassen der Parameter n und τ kann die Verzögerung reduziert werden, allerdings ist dies nur begrenzt möglich. Wird die Periode τ zu klein gewählt, so steigt der Kommunikationsaufwand, was eine Reduzierung der für Nutzdaten verfügbaren Bandbreite zur Folge hat. Wird n zu klein gewählt, werden Verbindungen schon bei sporadisch auftretenden Paketverlusten abgebaut. Die Vermaschung im Netz nimmt dadurch ab, die Verfügbarkeit wird herabgesetzt. Bei einem akzeptablen Kompromiss zwischen den genannten Kriterien würde die Verzögerung Δ t im Bereich von wenigen Sekunden liegen. Da eine Beschleunigung der Ausfallerkennung mit Verfahren der Nachbarschaftssuche innerhalb des Routingprotokolls demnach nicht im erforderlichen Maß möglich ist, sind andere Ansätze nötig. Bei Kommunikationssystemen werden einzelne Protokolle in verschiedenen Schichten realisiert. Damit sich eine drahtlose Kommunikation nach IEEE 802.11 nach oben hin ähnlich dem klassischen Ethernet verhält, sieht der Standard besondere Mechanismen vor. Innerhalb der MAC-Schicht (medium access control)

Früherkennung von Verbindungsausfällen in Mesh-Netzwerken

69

wird der Empfang eines Pakets vom Empfänger bestätigt. Bleibt die Bestätigung aus, so wird das Paket erneut übertragen. Dies wiederholt sich in beschränktem Umfang. Wenn diese Informationen der MAC-Schicht dem darüberliegenden Routingprotokoll zur Verfügung gestellt werden, kann ein Verbindungsausfall ohne zusätzlichen Kommunikationsaufwand deutlich früher erkannt werden. Wie bereits oben diskutiert, ist eine drahtlose Kommunikation prinzipiell störanfällig. Demnach kann die Verbindung nicht nach einem einzelnen Übertragungsfehler als ausgefallen klassifiziert werden. Die Entscheidung muss anhand eines geeigneten Fehlermodells erfolgen. Bei der Erstellung des Fehlermodells ist zu beachten, dass Übertragungen mit unterschiedlichen physikalischen Datenraten erfolgen können, wodurch die jeweilige Fehlerwahrscheinlichkeit beeinflusst wird. Die Datenrate wird von den Hardware-Treibern festgelegt und kann zwischen den einzelnen Übertragungsversuchen eines Paketes variieren. Ein mögliches Fehlermodell basiert auf der Anzahl der konsekutiven Übertragungsfehler mit der Basisdatenrate. Hierbei werden einzelne Übertragungsversuche innerhalb der MAC-Schicht betrachtet, wobei nur die berücksichtigt werden, die unter Verwendung der geringsten physikalischen Datenrate erfolgen. Da hier die Fehlerwahrscheinlichkeit die geringste ist, lässt ein Fehler eher auf einen Verbindungsausfall schließen als bei der Verwendung höherer Raten. Bei jedem Übertragungsfehler unter Verwendung der Basisdatenrate wird ein Zähler n f erhöht. Bei einer erfolgreichen Übertragung wird der Zähler zurückgesetzt. Übersteigt der Wert das Maximum nmax wird ein f Verbindungsausfall angenommen. festzulegen, wurde das Fehlermodell in Um geeignete Werte für den Parameter nmax f verschiedenen Szenarien kalibriert. Zum einen wurde ein stationäres Szenario verwendet, bei dem die Kommunikation zwischen zwei nah beieinander stehenden Stationen betrachtet wurde. Unter der Annahme, dass diese Verbindung stabil ist, sollten bei einem geeigneten Parameter hier keine Fehlalarme erzeugt werden. In einem weiteren Szenario wurde der abrupte Ausfall einer Station simuliert. Hierbei war die Latenz der Ausfallerkennung durch geeignete Parameter zu minimieren. Bei der Betrachtung beider Szenarien ergab sich nmax = 4 als geeigneter Parameter. f

3 Evaluierung Die schichtübergreifende Früherkennung von Verbindungsausfällen wird zur Evaluierung exemplarisch innerhalb des MadWifi-Treibers1 für Atheros-WLAN-Karten und des Routingprotokolls AWDS2 (Adhoc Wireless Distribution Service) umgesetzt. Es wird ein Verbindungsausfall durch den Ausfall einer Station herbeigeführt. Dabei wird die Anzahl der Paketverluste mit und ohne den Einsatz der Früherkennung betrachtet. Abbildung 1 zeigt das Ergebnis von jeweils 200 Versuchen mit unterschiedlichen Senderaten. Während ohne Verwendung der Früherkennung abhängig von der Senderate 100 bis 1 000 Pakete verloren gehen, kann durch die schichtübergreifende Früherkennung die Anzahl der Paketverluste auf einen von der Senderate unabhängigen Wert von maximal 4 reduziert werden. 1 2

        

T. Lindhorst

Anzahl Paketverluste (min/avg/max)

70

ohne Früherkennung mit Früherkennung 1000

100

10

1 10 Pkt/s

50 Pkt/s

100 Pkt/s

Datenstrom

Abb. 1: Paketverluste bei einem Stationsausfall

Neben der Evaluierung wird anhand einer Fallstudie zur Teleoperation eines Roboters gezeigt, dass es mit der schichtübergreifenden Ausfallerkennung möglich ist, WMNs für typische Echtzeit-Anwendungen einzusetzen. Dabei werden Steuerdaten von einem Operator zum Roboter gesendet und gleichzeitig ein Videobild vom Roboter zum Operator übertragen. Bewegt sich der Roboter innerhalb des Netzes, so fallen einzelne Verbindungen aus. Der Ausfall muss erkannt werden, damit die Kommunikation über eine alternative Route fortgesetzt werden kann. Bei einer herkömmlichen Ausfallerkennung ausschließlich durch Beaconing ist die Verbindung zum Roboter dabei für einige Sekunden unterbrochen. Nur durch die Verwendung der Früherkennung ist es möglich, den Roboter innerhalb des gesamten Netzes unterbrechungsfrei fernzusteuern.

4 Fazit In dieser Arbeit konnte nur ein Teil der Inhalte der zugrunde liegenden Diplomarbeit vorgestellt werden. Es wurde auf Verweise zu anderen Arbeiten verzichtet. Weiterhin fehlt die Betrachtung eines zweiten Fehlermodells und die detaillierte Erklärung der Kalibrierung der beiden Modelle sowie eine Beschreibung der Implementierung. Neben einem weiteren Evaluierungsszenario mit einer mobilen Station wird in der Diplomarbeit das Fallbeispiel zur Teleoperation eines mobilen Roboters ausführlich erläutert. Dennoch konnte hier gezeigt werden, dass durch den vorgestellten schichtübergreifenden Ansatz Verbindungsausfälle in drahtlosen Mesh-Netzwerken deutlich schneller erkannt werden können. Die Anzahl der dabei auftretenden Paketverluste kann unabhängig von der Senderate beschränkt werden und reduziert sich von beispielsweise mehreren Hundert auf maximal 4. Durch die höhere Zuverlässigkeit und Verfügbarkeit können WMNs ein breiteres Anwendungsfeld erschließen und für EchtzeitAnwendungen eingesetzt werden.

Konzept zur Übertragung von Daten in verteilten Echtzeitsystemen via Ethernet Werner Pirkl Hochschule Landshut Fakultät Informatik   

Zusammenfassung. Immer höher werdende Datenraten und größer werdende Verteilung von Echtzeitsystemen lässt bestehende, parallele Bussysteme als Übertragungsmedium zwischen Rechnern schnell Grenzen erreichen. In einem Prototyp wird deshalb versucht, Echtzeitdaten mit Hilfe eines Kommunikationsmodells über Ethernet zu verteilen.

1 Einleitung In verteilten Echtzeitsystemen wird es immer schwerer, Daten innerhalb bestimmter Zeitgrenzen von einer Quelle zum Ziel zu transferieren. Besonders schwierig wird dies bei tiefen Bushierarchien. In einem komplexen Testsystem für Flugzeuge eines europäischen Konzerns wird dies besonders deutlich. Da die Datenrate innerhalb von Flugzeugen stetig steigt, muss das System immer schneller auf deren Veränderungen reagieren, um Daten verlässlich auswerten, speichern oder verändern zu können.

Abb. 1: Aktuelle Systemarchitektur

Ein Flaschenhals dieses Testsystems stellt derzeit die Verbindung zweier Teilsysteme dar. Die aktuelle Architektur zeigt Abb. 1. Sie besteht im Wesentlichen aus Prozessorkarten auf PowerPC Basis, die über einen gemeinsamen VMEbus kommunizieren

72

W. Pirkl

und signalspezifische PCI Mezzanine Cards, die als Schnittstelle zwischen Flugzeugbussystem und dem Testsystem dienen. Aus Platz- und Energiegründen können oft nicht alle Karten in einem einzigen VMEbus Gehäuse untergebracht werden. Es ist daher notwendig, eine Kommunikation über mehrere Chassis zu ermöglichen, was durch einen parallelen Bus, den sogenannten PVIC1 ermöglicht wird. Ein Nachteil dabei sind die steigenden Latenzzeiten, die sich bei einer Serialisierung der Buszugriffe ergeben (z.B. PCI - VMEbus - PVIC - VMEbus - PCI). Schreibzugriffe sind wegen der Write-Posting Funktion moderner Brücken weniger stark davon betroffen als Lesezugriffe. Schließlich behindern sich die Datenzugriffe gegenseitig auf den Bussystemen: Ein Prozess, der schnittstellenspezifische Daten verarbeitet, greift bei Bedarf über alle Bussysteme hinweg auf ein Wort zu und beeinflusst damit auch die Zugriffe aller anderen Prozessorkarten.

2 Grundgedanken Wie in Kapitel 1 festgestellt wurde ist Schreiben wesentlich effizienter als Lesen. Um dies umzusetzen, muss zunächst erkannt werden, wann sich Daten ändern. Leider verfügen aktuelle Schnittstellenkarten nicht über genügend Rechenleistung, um eine solche Methodik zu implementieren. Daher wird ein Kompromiss eingegangen und die Anzahl der involvierten Bussysteme auf ein Minimum reduziert, indem Daten von einem zusätzlichen Rechner gelesen und versendet werden. Um nun die Daten zu verteilen benötigt die Quelle Kenntnis darüber, wo diese im System benötigt werden. Durch die Einführung eines Abonnenten Systems kann jedes Ziel die Daten anfordern, die es benötigt. Es wird dadurch auch die Anzahl der Schreibzugriffe begrenzt, um alle Ziele zu behandeln. Durch diese Methoden wird eine Grundlage von lokalem Lesen und globalem Schreiben erreicht. Verwendet man ein nicht echtzeitfähiges Medium wie Ethernet als Überträger, müssen zunächst Voruntersuchungen gemacht werden, um die Worst-Case Latenzen zu ermitteln und mögliche Fehlerursachen zu erkennen. Ein wichtiger Aspekt – speziell bei Ethernet – ist die Datensicherheit. Verwendet man ein leichtgewichtiges, schnelles Protokoll wie das User Datagram Protocol, muss sich der Benutzer um das Absichern gegen Paketverluste kümmern. Das Transport Control Protocol stellt hier eine sichere Datenübertragung bereits auf Protokollebene her, schränkt aber durch Kontrollframes Latenz und Bandbreite ein und erhöht dadurch die Worst-Case Übertragungszeit.

3 Kommunikationskonzept Das Konzept, wie es in Abb. 2 dargestellt ist, basiert auf einem sehr flexiblen Ansatz zum Austausch von Daten. Es verwendet bereits bestehende Schnittstellentreiber und ermöglicht in einem dreistufigen System die Auswahl von Einzelkomponenten wie die Übertragungsmethoden dynamisch zur Laufzeit, oder statisch bei der Übersetzung. Es ist nicht zwangsläufig auf Ethernet als Übertragungsmedium festgelegt. 1

Parallel Versatile InterConnect Bus, ein transparenter VME zu VME Überträger

Übertragung von Echtzeitdaten via Ethernet

73

Herzstück der Kommunikation bildet hier der Transport Layer. Der Grundgedanke des globalen Schreibens wird hier implementiert, indem vom System kommende Nachrichten an die von ihm verwalteten Zielverbindungen gesendet werden. Ankommende Daten werden im System weiter geleitet und an die entsprechenden Schnittstellen geschrieben. Die Absicherung gegen Übertragungsfehler wird bei ungesicherten Verbindungen durch protokollspezifische Verfahren garantiert. Daten können hier mittels Multicast an mehrere Systeme gesendet werden. Aber auch gesicherte Übertragungswege wie TCP werden unterstützt.

Abb. 2: Kommunikationsarchitektur

Die detaillierte Übersicht einer Realisierung der Datenübertragung mittels UDP zeigt Abb. 3. Die Methoden „senden“ und „empfangen“ des Transport Layers sind standardisiert. Somit können eigene Übertragungsmedien einfach eingebunden werden. Da UDP die Übertragung nicht sichert, wird jede Nachricht auf die maximale Paketgröße des Mediums (MTU) gekürzt und auf der Empfängerseite zusammengefügt. Ein Zeitstempelmechanismus erkennt dabei verloren gegangene Pakete, die durch ein senderseitiges Zwischenspeichern nochmals übertragen werden können. Der Prepare Layer definiert die Logik zwischen dem Transport Layer und der Anbindung dessen an Schnittstellen und verarbeitende Prozesse. Von Abonnenten kommende Daten werden mit allen registrierten Zieladressen und Metadaten gekoppelt und an den Kommunikations Layer übergeben. Eintreffende Daten werden direkt an die entsprechenden Treiber weitergereicht, von welchen sie bei Bedarf durch die Prozesse lokal gelesen werden können.

74

W. Pirkl

Eine Ausnahme besteht bei Lesezugriffen auf Schnittstellen. Diese werden ausschließlich von einer Benachrichtigungsschicht, dem Notification Layer, behandelt. Mit Hilfe eines Pollingmechanismus oder eventgestützt über spezielle Hardware FIFOs werden aktualisierte Daten erkannt. Anschließend werden anhand einer Tabelle die Nachrichten ausgewählt, die nun versendet, das heißt an den Prepare Layer übergeben werden müssen. Der Notification Layer stellt damit die Implementierung des lokalen Lesens dar.

Abb. 3: Transportlayer UDP

Neue Processing Treiber verbinden die Rechenprozesse mit der Kommunikationsarchitektur. Sie kommunizieren mit dem System über Software FIFOs, die mit Hardware FIFOs gekoppelt sind. Durch ein Nachbilden der bisher verwendeten Treiber für die Schnittstellenkarten wird eine Anpassung der bereits bestehenden Prozesse vermieden. Schließlich hilft ein Vorrat von Bufferelementen dabei, die Kopiervorgänge innerhalb des Kommunikationssystems zu minimieren. Bereits bei der Initialisierung werden dazu vom System verschieden große Speicherblöcke angefordert, vorformatiert, und an zentraler Stelle verwaltet. Zu lesende Daten werden dann an die Stelle innerhalb eines passenden Bufferelements kopiert, die der beim Verlassen des Systems entspricht. Metadaten werden dann vor den eigentlichen Nutzdaten angefügt, ohne diese dabei verschieben zu müssen.

4 Ergebnisse Der aktuelle Prototyp ist aufgrund einer fehlenden Optimierung der Datenübertragung mittels DMA und unausgereifter Netzwerkkonfiguration noch nicht in der Lage, einen parallelen Echtzeitbus zu ersetzen. Messungen der Latenz und Bandbreite von Ethernet und Kommunikationssystem lassen dies jedoch als möglich erscheinen. Die maximale Latenz von der Generierung einer Nachricht bis zu deren Speicherung im Zielsystem liegt im Rahmen von wenigen Millisekunden. Die mittlere Übertragungszeit liegt im Bereich von 300 bis 4000 Mikrosekunden und ist ausschließlich von der Nachrichtengröße abhängig. Die Latenzzeit bei Verwendung des Transport Control Protocols ist um einen Faktor zwischen zwei und vier höher.

Echtzeitfähigkeit des VxWorks Netzwerkstacks Stefan Zeltner Hochschule Landshut Fakultät Informatik     

Zusammenfassung. In der Echtzeitdatenverarbeitung war bisher eine ethernetbasierte Interprozessorkommunikation selten anzutreffen. Doch Ethernet hat sich in den letzten Jahren rasant entwickelt und scheint, zumindest für spezielle Szenarien oder den Low-Cost Sektor, eine einfach zu implementierende, aber flexible und vor allem kostengünstige Alternative zu bisherigen Systemen darzustellen. Vor dem Einsatz in einem kommerziellen Projekt sollte eine genaue Analyse der Echtzeitfähigkeit durchgeführt und zukünftige Risiken abgeschätzt werden. Dieser Artikel präsentiert einige Gedanken zur Thematik und führt diese kurz am Beispiel des VxWorks Netzwerkstacks aus.

1 Einleitung War Kommunikation über das Ethernet-Protokoll in der Vergangenheit bei Echtzeitsystemen nur in Verbindung mit Programmentwicklung, Wartung und echtzeitunkritischen Anwendungen wie Logging oder Monitoring üblich, so ist der heutige Stand der Technik durchaus interessant für Echtzeitanwendungen. Der Grund dafür wird nicht sofort ersichtlich: Der Durchsatz ist bei aktuellen PCI oder PCI-Express Bussystemen theoretisch größer, zudem ist es komplizierter, ein Worst-Case-Szenario für Ethernetsysteme zu konstruieren. Bei komplexeren Systemen spielt Ethernet seine Stärken aus: Zum Beispiel läuft bei einem VMEbus-basierten System die Kommunikation zwischen zwei CPU-Karten typischerweise über fünf Busse. Dadurch werden diese für alle anderen Teilnehmer gesperrt, wodurch die Latenzzeit der Übertragung ansteigt und der Durchsatz teilweise massive Einbrüche erleidet. Über einem Ethernet-Switch kann hingegen eine sternförmige Punkt-zu-Punkt Architektur zwischen den CPUs realisieren werden. Dadurch können, mit geeigneter Hardware, parallel mehrere Verbindungen mit voller Geschwindigkeit errichtet werden, die unabhängig von der räumlichen Anordnung der Prozessorkarten sind. Auch in finanzieller Hinsicht ist die Ethernet-Technologie interessant. So sind die meisten Komponenten Massenware und dementsprechend preiswert.

2 Echtzeitfähigkeit des Ethernet-Protokols Weshalb werden dann ethernetbasierte Kommunikationsmodelle nicht häufiger in Systeme mit harten Echtzeitbedingungen eingesetzt? Das Problem ist nicht die mittlere

76

S. Zeltner

Performance, sondern die schwierige Worst-Case-Berechnung des Datentransfers. Das Problem liegt schon in der Architektur des Protokolls: Dieses wurde für nichtechtzeitfähige Systeme entwickelt und auf maximalen durchschnittlichen Durchsatz optimiert, nicht auf verlässliche Aussagen über die maximale Dauer eines Sende- oder Empfangvorgangs. Um die harte Echtzeitbedingung aber verlässlich zu erfüllen ist diese Zeit notwendig. Eine Lösung ist, die bestehenden Standards und Algorithmen als Basis für eigene Produkte zu nutzen. Dieser Ansatz hat den Vorteil, dass das komplette Design auf die Echtzeitanforderungen abgestimmt werden kann. Allerdings müssen dafür meist angepasste Hardware, neue Protokolle und eigene Netzwerkstacks eingeführt werden. Durch diese Eigenentwicklungen können nicht alle Vorteile des „normalen“ Ethernet genutzt werden. Das Netzwerk ist dann eine Art Feldbus und für den Anwender meist transparent. Allerdings können durch vorhandene Technologien und Know-How Entwicklungszeit und Herstellungskosten gesenkt und teilweise sogar Standardhardware benutzt werden (Zwei beispielhafte Vertreter sind AFDX und EtherCAT). Etablierte Ethernet Hard- und Software zu benutzen ist die andere Möglichkeit. Dies hat die Vorteile, dass Anwendungsprogramme großteils Betriebssystem- und Hardwareunabhängig entwickelt werden können, da heutzutage die meisten Prozessorkarten eine oder mehrere Ethernetschnittstellen besitzen und alle gängigen Betriebssysteme die standardisierte Berkeley-Socket-API anbieten. Diese müssen aber von Fall zu Fall genau analysiert werden, um dann möglichst genaue Laufzeiteigenschaften vorhersagen zu können. Probleme hierbei bereitet das Design der vorhandenen Komponenten. Angefangen bei Netzwerkkarten mit CSMACD, die eine zufällige Zeit warten, um Kollisionen zu vermeiden, über den Datentransport von der Netzwerkkarte zum Speicher und dem Netzwerktreiber bis hin zum betriebssystemeigenen Netzwerkstack, welcher protokollspezifische Verzögerungen wegen Adressauflösung (ARP oder DNS) oder Routing verursacht, ist es ein schwieriges Unterfangen, eine maximale Prozesslaufzeit zu bestimmen. Weitere Worst-CaseParameter finden sich in [1]. Es wird nun ein Ansatz gezeigt, wie der mitgelieferte Netzwerkstack von VxWorks vermessen werden kann.

3 Der VxWorks Netzwerk Stack Der VxWorks Netzwerk Stack ist ein fester Bestandteil des VxWorks Betriebssystems, der allerdings öfters angepasst oder ausgetauscht wurde. Meist war es jedoch nicht die Echtzeitfähigkeit, die im Mittelpunkt der Neuerungen stand, sondern die Implementierung von Netzwerkstandards und die Annäherung an die Unix-übliche API. Dies hat neben dem Vorteil, dass Anwendungen nun leichter plattformunabhängig entwickelt werden können, den gravierenden Nachteil, dass auch die VxWorks Versionen untereinander verschiedene Laufzeitergebnisse aufweisen können. Hier ist ein Testprogramm vorteilhaft, das unter allen Versionen ohne große Änderungen lauffähig ist. Der VxWorks Netzwerkstack ist eingebettet in zwei Abstraktionslayer: Der eine ist die VxWorks-Socket-API, eine Schnittstelle, die dem Anwender standardisierte Zugrif-

Echtzeitfähigkeit des VxWorks Netzwerkstacks

77

fe per Berkeley-Socket-API auf den Netzwerkstack und die darunterliegenden Treiber ermöglicht. Zwischen Treiber und Netzwerkstack befindet sich ein zweites Interface: Der MUX-Layer. Dieser wurde zur VxWorks Version 5.5 zusammen mit den END Treibern eingeführt und soll die Entwicklung von Treiber und das Einbinden von neuen Netzwerkprotokollen mit eigenen Netzwerkstacks erleichtern und unabhängig voneinander machen. Dabei fungiert er als Multiplexer, der eingehende Pakete anhand des Typs den passenden Netzwerkservice und ausgehende an den zugehörigen Treiber übergibt. Beim Senden eines Paketes wird zuerst der Netzwerkstack und dann der Treiber im aktuellen Anwendungskontext aufgerufen. Um dagegen beim Empfangen eines Paketes nicht zu lange in einer Interruptserviceroutine zu verweilen, wird es von ihr an den tNetTask (Priorität 50) übergeben. Dieser übergibt das Paket je nach Inhalt entweder an eine wartende Applikation oder führt protokollspezifische Aktionen aus (zum Beispiel das Schicken eines ARP Replays auf einen ARP Request). Für Übertragungssteuerungsprotokolle wie TCP muss die tNetTask beim Senden aktiv werden, um die Bestätigung abzuwarten.

4 Relevante Daten Um die Echtzeitfähigkeit des Netzwerkstacks festzustellen, muss dieser untersucht werden, ob und unter welchen Umständen bestimmte Worst-Case-Zeiten auftreten. Mittels empirischer Messung kann eine erste und einfache Abschätzung dieser Zeiten durchgeführt werden. Hierzu werden vier Zeitstempel benötigt, welche die Durchlaufszeit des Netzwerkstacks repräsentieren. Tabelle 1 zeigt beispielhaft, an welcher Stelle sie genommen werden. Appl. → Stack Stack → Treiber Treiber → Stack Stack → Appl.              



  

   

    

Tabelle 1: Speicherung der Zeitstempel

Liegt der Quellcode des Netzwerktreibers nicht vor, können mit Hilfe der Paketfilterfunktion des MUX Interfaces die Zeitstempel generieren werden [1]. Mit diesem Environment können lang angelegte Tests realisiert und so die Netzwerkstackdurchlaufszeiten in Abhängigkeit von verschiedenen Parametern getestet werden. Interessante Parameter sind zum Beispiel die Cachearchitektur und die Cachepolicies, die verwendete Netzwerkhardware oder die Betriebssystemversion. Eine initiale Proof-of-Technology Abschätzung hat gezeigt, das die Streuung der Stackdurchlaufszeit immer unter 50 Mikrosekunden liegt. Dies ist ein durchaus akzeptabler Wert, da in die Messungen Störfaktoren wie zum Beispiel Cacheeffekte einflossen. Ermutigt durch diese Zahlen steht einer Verifizierung der Messergebnisse und eine genaue Analyse der verschiedenen Einflussfaktoren nichts mehr im Wege [1]. Das nachfolgende Beispiel ist ein Ausschnitt aus diesen ersten Messreihen.

78

S. Zeltner

5 VxWorks 5.5 vs. 6.6 Das Testszenario besteht aus zwei Motorola MVME 3100 CPU-Karten. Da nur die Stackdurchlaufszeit vermessen wird ist die verwendete Netzwerkhardware nicht von Bedeutung. Auf diesen beiden Prozessorkarten kommen in zwei Testreihen einmal VxWorks 5.5 und einmal VxWorks 6.6 zum Einsatz. Dies ist insbesondere interessant, da der Netzwerkstack in der Version 6.5 vollständig ausgetauscht wurde. Das Ergebnis ist in Abb. 1 zu sehen. Erwartungsgemäß ist die Durchlaufszeit, aber auch die Streuung von VxWorks 6.6 schlechter als von VxWorks 5.5, da der Fokus des neuen Netzwerkstacks nicht auf Echtzeitfähigkeit liegt.

1000

Network-Stack throughput Time (microseconds)

Incoming packet, VxWorks 6.6 Outgoing packet, VxWorks 6.6 Incoming packet, VxWorks 5.5 Outgoing packet, VxWorks 5.5

100

10 100

1000

10000

Payload (byte)

Abb. 1: Netzwerkstacksdurchlaufszeit VxWorks 5.5 im Vergleich zu VxWorks 6.6

Literaturverzeichnis 1. Zeltner S.: Real-time Performance of the VxWorks Network Stack. Bachelor Thesis, Landshut, University of Applied Sciences, 2009

Kommunikationsanforderungen an verteilte Echtzeitsysteme in der Fertigungsautomatisierung Roman Just und Henning Trsek inIT - Institut Industrial IT, Liebigstr. 87, 32657 Lemgo         

Zusammenfassung. Kommunikationssysteme der Automatisierung müssen hohe zeitliche Anforderungen erfüllen, damit die entsprechenden industriellen Anwendungen realisiert werden können. Im Gegensatz zum IT-Bereich sind diese Anforderungen jedoch häufig nicht genau bekannt, was insbesondere beim Einsatz von drahtlosen Technologien Probleme bereiten kann1 . In dieser Arbeit werden Verkehrsmuster einer realen Anlage aus dem Bereich der Fertigungsautomatisierung bestimmt. Die Zwischenankunfts- und Latenzzeiten einzelner Sensorund Aktorsignale ermöglichen Rückschlüsse auf zeitliche Anforderungen und Charakteristiken der untersuchten Anwendung. Im Anschluss werden die erzielten Erkenntnisse hinsichtlich ausgewählter Kommunikationsanforderungen analysiert und aktuell gültige Anforderungen von realen Automatisierungsanlagen abgeleitet. Weiterhin werden sie zukünftig zur Entwicklung realitätsnaher Simulationsmodelle genutzt.

1 Einleitung Anwendungen in der Fertigungsautomatisierung stellen wegen ihrer hohen Dynamik häufig anspruchsvolle und hohe zeitliche Anforderungen [4] an das eingesetzte Kommunikationssystem. Um beispielsweise im Rahmen eines Maschinenumbaus etablierte Feldbusse durch lediglich ein alternatives Echtzeit-Ethernet System zu ersetzen, ist es zunächst notwendig, eine detaillierte Analyse dieser Anforderungen durchzuführen. Außerdem sind die zeitlichen Anforderungen für die Einführung drahtloser Technologien von großem Interesse, die aufgrund vieler Vorteile immer öfter zum Einsatz kommen [12]. Weiterhin können die gewonnenen Erkenntnisse zur Entwicklung von Verkehrsmodellen für Simulationsstudien eingesetzt werden. Die Analyse kann durch eine Aufzeichnung der Kommunikation an der laufenden Anlage und der anschließenden Auswertung des Datenverkehrs erfolgen. Die Auswertung erfolgt im Hinblick auf verschiedene Kriterien. Dieses Vorgehen ist ein bekannter Ansatz im Umfeld von Local Area Networks (LAN) und Wide Area Networks (WAN). Es gibt bereits viele Arbeiten in diesem Gebiet (siehe [3]), es sind allerdings nur wenig Forschungsergebnisse im Bereich der industriellen Automatisierung verfügbar. Jasperneite et al. [7] haben ein Kommunikationssystem einer Anlage der Fertigungstechnik untersucht, um daraus ein repräsentatives Verkehrsmodell für eine simulative und analytische Leistungsbewertung abzuleiten. Hierfür wurde der Datenverkehr 1

Die Arbeit ist Teil des Forschungsprojekts "RAvE - Realtime Automation Networks in moving Industrial Environments"mit dem Förderkennzeichen 1787A07 gefördert vom BMBF.

80

R. Just, H. Trsek

der Anlage eine Woche aufgezeichnet. Die Ergebnisse basieren auf der Verteilung von Ankunftszeiten, der Verteilung von Paketgrößen und der zeitlichen Charakteristiken der versendeten Nachrichten. Das Kommunikationssystem bestand im Wesentlichen aus dem Feldbussystem Interbus [5]. In dieser Arbeit wird eine Anlage mit einem heterogenen Kommunikationssystem untersucht, die die Feldbussysteme Interbus [5], Sercos II [10] und Modbus/TCP [9] basierend auf Ethernet [1]. Aus den Messungen werden Verkehrsmuster und die entsprechenden zeitlichen Anforderungen abgeleitet.

2 Untersuchungsgegenstand Bei der zu untersuchenden Anlage handelt es sich um eine Maschine, die zur Erprobung neuer Technologien und Konzepte betrieben wird. Die Bus- und Netzwerkkonfiguration der Maschine ist in Abbildung 1 dargestellt. Es handelt sich hier um einen komplexen Aufbau mit mehreren Steuerungen, Antrieben, sowie Sensoren und Aktoren. Grundsätzlich lässt sich der Versuchsaufbau zunächst in die drei vorherig genannten Feldbussysteme gliedern. Sercos II übernimmt die Ansteuerung der Antriebe, die Sensor- und Aktorkommunikation wird mit Interbus realisiert und Modbus/TCP ist für den Austausch von Parametern und Fehlermeldungen zuständig. Die Anlage ist mit einer zentralen Steuerung ausgestattet. Hierbei handelt es sich um eine PC-basierte All-in-One Steuerlösung, d. h. es werden die Funktionen einer SPS geboten und je nach Ausführung kann ein Touchscreen integriert sein (z. B. als Bedienschnittstelle). In der zu untersuchenden Anlage ist die Steuerung mit einem Interbus- und einem Sercos II-Master ausgestattet. Für Modbus/TCP wird das serienmäßig integrierte Ethernet Interface verwendet. Über den Sercos II-Master werden zwei Antriebe (Sercos II Slaves) angesteuert. Der Interbus Master ist über den Fernbus mit einer Kompaktsteuerung ILC 370, mehreren I/O-Knoten und dem Industrie-PC 5100 verbunden. Über Ethernet bzw. Modbus/TCP werden einerseits Signale, die für sicherheitsrelevante Aspekte der Anlage zuständig sind, und andererseits Displays für die Ausgabe von Parametern und Fehlermeldungen angebunden. 2.1 Produktionsanlage Bei der Phoenix Contact Konzeptmaschine handelt es sich um eine reale Produktionsanlage aus dem Bereich der Fertigungsautomatisierung zur Herstellung von Steckverbindern. Sie dient dem Unternehmen zur Erprobung neuer Technologien und Maschinenkonzepte. Da die Anlage ausschließlich für Demonstrationszwecke eingesetzt wird, sind einige mechanische Komponenten sowie Stationen, ohne Funktion bzw. in ihrer Funktion eingeschränkt, welches jedoch keinen Einfluss auf die Kommunikationscharakteristiken hat. Der Ablauf der Produktionsanlage ist in einzelne Stationen unterteilt. Insgesamt werden neun Stationen durchlaufen, bis ein Steckverbinder vollständig zusammengesetzt und auf Fehler geprüft ist. Für einen vollständigen Durchgang (Station 1 - Station 9) benötigt ein Werkstück ca. 165 s. Die Zuführung der Werkstücke zu den einzelnen Stationen ist durch die dafür konzipierten Werkstückträger, die häufig auch als

Kommunikationsanforderungen an verteilte Echtzeitsysteme

81

Abb. 1: Industrielle Produktionsanlage mit heterogener Kommunikationsstruktur

Nest bezeichnet werden, realisiert. Die Feinpositionierung der Träger an den verschiedenen Stationen wird durch einen Servomotor (Hauptantrieb) in Verbindung mit einem Kugelgewindetrieb durchgeführt. Der Rücktransport wird durch ein Transportband bewerkstelligt. An Station 1 werden die Steckverbinder-Gehäuse den Werkstückträgern zugeführt. Hierzu entnimmt ein Teile-Greifer ein Leergehäuse aus der Zuführung (Förderrinne) und setzt es in den Werkstückträger. Anschließend wird auf Station 2 durch eine Lichtschranke geprüft, ob sich das Werkstück in der richtigen Position im Werkstückträger befindet. Die dritte Station ist für das Einsetzen der Kontaktstifte in die Werkstückgehäuse zuständig. Station 4 stellt sicher, dass der zuvor eingesetzte Kontaktstift vollständig eingerastet ist. Zu diesem Zweck werden die Stifte der Reihe nach mit einem Pneumatikzylinder eingedrückt. An den Stationen 5 – 7 wird die Ausdrückkraftprüfung vorgenommen. Hiermit wird sichergestellt, dass sich kein Stift löst, wenn ein Stecker aus der Grundleiste einer Leiterplatte gezogen wird. Station 8 prüft die qualitativen Merkmale der Werkstücke unter Zuhilfenahme einer Kamera und dem IPC 5100 (Abb. 1). Die letzte Station sortiert die fertigen Artikel nach Gutteil und Ausschuss. Dazu wird, ähnlich der ersten Station, ein Teile-Greifer für das Entnehmen und Ablegen verwendet.

82

R. Just, H. Trsek

2.2 Interbus, Sercos II und Modbus/TCP Bei Interbus handelt es sich um einen international verbreiteten Feldbusstandard, optimiert für den Sensor-Aktor-Bereich [8]. Die Kommunikation des Interbus-Protokolls basiert auf dem Summenrahmenverfahren. Aus topologischer Sicht ist Interbus ein Ringsystem, d.h. alle Teilnehmer sind aktiv in einem geschlossenen Übertragungsweg eingebunden [8]. Bei Sercos II handelt es sich um eine speziell auf Antriebe ausgerichtete digitale Schnittstelle, die nach dem Master-Slave-Prinzip arbeitet [10]. Der Datenaustausch zwischen den Teilnehmern findet auf Grundlage einer monomasterfähigen Ringstruktur statt. Der Zugriff auf das Übertragungsmedium ist durch ein Zeitschlitzverfahren realisiert [13]. Im Gegensatz zu den anderen beschriebenen Standards kommen bei Sercos II Lichtwellenleiter (LWL) als Übertragungsmedium zum Einsatz. Modbus/TCP ist eines der ersten Ethernet-basierten Feldbussysteme und wird hauptsächlich in der Fertigungsautomatisierung eingesetzt [9]. Das Modbus/TCP Protokoll ist eine Weiterentwicklung des bereits 1979 hervorgebrachten Modbus-Standards. Dabei wurden die Modbus-Dienste sowie das Kommunikationsmodell aus dem Standard übernommen und auf TCP/IP abgebildet [9].

3 Erfassung und Auswertung der Daten Der erste Schritt zur Ermittlung der Kommunikationsanforderungen der im vorherigen Kapitel beschriebenen Konzeptmaschine ist die gleichzeitige Aufzeichnung der gesamten Kommunikation. Die zentrale speicherprogrammierbare Steuerung (SPS) hat drei verschiedene Kommunikationsschnittstellen, deren Verkehr gleichzeitig von einem PC mit spezieller Analyse-Hardware, die während der Messungen zeitlich synchron arbeitet, aufgezeichnet wird. Die aufgezeichneten Nutzdaten werden mit den in der Anlage projektierten Eingangs- und Ausgangssignalen verknüpft. Dadurch können die zeitlichen Verläufe der Zwischenankunftszeiten der einzelnen Sensor- und Aktorsignale extrahiert, statistisch ausgewertet und hinsichtlich ihrer Verteilung bewertet werden. Neben der Bewertung der Zwischenankunftszeiten einzelner Prozesssignale werden die Einflüsse der heterogenen Kommunikationsstruktur untersucht. Die Datenerhebung erfolgt auf der Leit-, Prozess- und der Feldebene, aufgezeichnet wurde sämtlicher Datenverkehr in zwei im Vorfeld definierten Messszenarien. Da es sich hierbei um eine reale industrielle Produktionsanlage handelt, kann das Anwendungsverhalten während der Messung nicht beeinflusst werden. Die Aufzeichnung erfolgt daher nach der Methode der passiven Überwachung (Monitoring) [6], die mit Hilfe eines für das jeweilige Bussystem entsprechenden Protokollanalysators durchgeführt wird. Die Analyse des Sercos II Protokolls wurde mit dem Sercos Monitor durchgeführt, der sowohl aus Hardware- als auch aus Softwarekomponenten besteht und von der Hilscher GmbH bereitgestellt wurde. Des Weiteren wurde der Protokollanalysator netANALYZER (ebenfalls von der Hilscher GmbH) für Modbus/TCP verwendet. Die Auswertung der aufgezeichneten Daten erfolgte mit der frei erhältlichen Software Wireshark. Die Aufzeichnung des Interbus Protokolls erfolgte mit einem vorhandenen Interbus Analyzer, der ebenfalls aus einer Hard- und Software Kombination bestand.

Kommunikationsanforderungen an verteilte Echtzeitsysteme

83

Das erste Messszenario beschränkte sich auf die Bussysteme Interbus und Modbus/TCP. Die Gesamtdauer der Messung betrug ca. 2 h und wurde im Vorfeld anhand beispielhafter Messungen bestimmt (siehe [6]). Ziel dieser Messung war die Untersuchung einzelner Sensor- und Aktorsignale und deren anschließende statistische Bewertung unter dem Kriterium der Zwischenankunftszeit. Außerdem wurden die Messergebnisse hinsichtlich der entstehenden Latenzzeiten ausgewertet. Für das zweite Messszenario wurden die Bussysteme Interbus, Sercos II und Modbus/TCP herangezogen. Die Messdauer wurde entsprechend vorhandener Einschränkungen bezüglich der Aufzeichnungsdauer des Sercos II Protokollanalysators ausgelegt und hatte daher eine Gesamtdauer von ca. 7 min. Ziel dieser Messung war der Nachweis von Signalabhängigkeiten innerhalb der heterogenen Kommunikationsstruktur und die Bestimmung vorhandenen Latenzzeiten.

4 Ergebnisse und Kommunikationsanforderungen Im ersten Schritt konnten aus der Datenerhebung für das erste Messszenario einzelne Sensor- und Aktorsignale extrahiert werden. Im Folgenden werden diese unter dem Kriterium der Zwischenankunftszeit (TE ) statistisch bewertet und grafisch veranschaulicht. Die zeitlichen Verläufe der Zwischenankunftszeiten werden hierbei als Histogramm H(TE ) und als empirische Verteilungsfunktion F(TE ) dargestellt. Grundsätzlich lassen sich die gewonnenen Ergebnisse zunächst in drei Leistungskategorien einteilen: 1. Hohe Anforderungen (≤ 100 ms) 2. Mittlere Anforderungen (≤ 1 s) 3. Geringe Anforderungen (≥ 1 s) Das Signal ST1_OUT_xOeffner_2_vor-Y (Interbus) steuert die Bewegung eines Aktors auf Station 1 und kann der Leistungskategorie hohe Anforderungen zugeordnet werden. Die bimodale Verteilung in Abbildung 2a ist auf die sequentielle Arbeitsweise des fertigungstechnischen Prozesses zurückzuführen. Es kann zwischen aktiven Phasen und passiven Phasen unterschieden werden. In den aktiven Phasen wird das Werkstück bearbeitet und in den passiven Phasen findet keine Bearbeitung des Werkstücks statt. In Abbildung 2b wird das Intervall ≤ 50 ms fokussiert, es handelt sich hierbei um die aktive Phase. Das Histogramm zeigt eine deutliche Häufung der Messwerte bei ca. 23 ms und 27 ms. Das Signal mit den vergleichsweise höchsten Anforderungen konnte an Station 3 identifiziert werden. Bei dem Sensorsignal ST3_IN_xStift_vorhanden-B (Interbus) handelt es sich um eine Lichtschranke. Mit dieser wird geprüft, ob ein Kontaktstift folgerichtig in das Werkstückgehäuse eingesetzt wurde. Abbildung 3b stellt einen feiner skalierten Bereich der zeitlichen Verläufe der Zwischenankunftszeiten dar (≤ 10 ms). Es ist eine Häufung der Messwerte bei ca. 3, 37 ms und 6, 5 ms erkennbar. Auffällig ist hierbei die Häufung der Messwerte bei 3, 37 ms, dieser Wert entspricht der InterbusBuszykluszeit. Es kann somit festgehalten werden, dass das Signal an die Leistungsgrenze des Bussystems herankommt. Da der Betrieb der Anlage allerdings während der

84

R. Just, H. Trsek

(a)

(b)

Abb. 2: Verteilung der ST1_OUT_xOeffner_2_vor-Y

Zwischenankunftszeiten

des

Signals

gesamten Messdauer fehlerfrei war, wird davon ausgegangen, dass die gebotene Leistung in diesem Fall ausreichte. Als Beispiel für ein Signal im mittleren Anforderungsbereich wurde das Sensorsignal ST3_IN_xStift_Greifer_zu-B untersucht. Die entsprechenden Zwischenankunftszeiten des Signals sind in Abbildung 4 dargestellt. Die Messwerte häufen sich bei ca. 400 ms und 500 ms. Auffällig ist, dass der Abstand zwischen den deutlich ausgeprägten Gipfeln deutlich kleiner ist, im Vergleich zu den bisher untersuchten Signalen. Dies ist dadurch begründet, dass die aktiven und passiven Phasen des fertigungstechnischen Prozesses eine ähnliche zeitliche Dauer haben. Für die Ableitung von Kommunikationsanforderungen ist neben der Zwischenankunftszeit (TE ) auch die Latenzzeit (TL ) von entscheidender Bedeutung. Betrachtet wurde die Zeitspanne zwischen Sendebeginn von der Quelle bis zur Ankunft an der Senke bzw. in diesem Fall vom Sensor bis zum Aktor. In Tabelle 1 sind Latenzzeiten für einzelne ausgewählte Aktor- und Sensorsignale (Interbus) veranschaulicht. Beson-

Kommunikationsanforderungen an verteilte Echtzeitsysteme

85

(a)

(b)

Abb. 3: Verteilung der ST3_IN_xStift_vorhanden-B

Zwischenankunftszeiten

des

Signals

Tabelle 1: Latenzzeiten verschiedener, betrachteter Signale i 1 2 3 4 5 6

Quelle ST1_IN_xOeffner_2 (Sensor) ST1_IN_xGeh_greifen_zu (Sensor) ST3_IN_xStift_Greifer_zu (Sensor) ST3_IN_xVereinzelung_unten (Sensor) ST4_IN_xEindruecker_vorne (Sensor) ST9_IN_xEntnahme_vorne (Sensor)

Senke Latenzzeit (TL ) ST1_OUT_xOeffner_2 (Aktor) 16ms ST1_OUT_xGeh_greifen_zu (Aktor) 42ms ST3_OUT_xStift_Greifer_zu (Aktor) 23ms ST3_OUT_xVereinzelung_ab (Aktor) 10ms ST4_OUT_xEindruecker_vor (Aktor) 10ms ST9_OUT_xEntnahme_vor (Aktor) 270ms

ders hohe Anforderungen sind in Station 3 und 4 vorzufinden und liegen bei 10 ms, eher geringe Anforderungen liegen bei 270 ms in Station 9. Um eine Bus-übergreifende Signalabhängigkeit nachzuweisen, wurden die zeitlichen Verläufe der Signale xDUSwivelUnitInFront-B und xDU1SwivelUnitBack-B (bei-

86

R. Just, H. Trsek

Abb. 4: Verteilung ST3_IN_xStift_Greifer_zu-B

der

Zwischenankunftszeiten

des

Signals

Abb. 5: Latenzzeiten Bus-übergreifend

de Interbus) in Abhängigkeit zu dem zeitlichen Verlauf des Hauptantriebs (Sercos II) betrachtet (Abbildung 5). Bei beiden Interbus-Signalen handelt es sich um Sensorsignale (Zylinderschalter) des Drehantriebs für die Schwenkleisten, welche gemäß der Bewegungsrichtung des Hauptantriebs abwechselnd true sind. Dem zeitlichen Verlauf des Hauptantriebs ist zu entnehmen, dass die längeren zeitlichen Abstände auf den Werkstückträgertransport zurückzuführen sind (Signal true). Die kurzen zeitlichen Abstände (Signal false) deuten auf den Werkstückträgerwechsel hin. Für den Hauptantrieb und das Sensorsignal xDU1SwivelUnitInFront-B wurde eine durchschnittliche Latenzzeit von 45 ms ermit-

Kommunikationsanforderungen an verteilte Echtzeitsysteme

87

telt. Des Weiteren konnte für das Sensorsignal xDU1SwivelUnitBack-B und den Hauptantrieb eine Latenzzeit von 48 ms bestimmt werden.

5 Zusammenfassung und Ausblick In dieser Arbeit wird eine reale Maschine aus dem Bereich der Fertigungsautomatisierung, die zur Produktion von Steckverbindern dient, herangezogen, um die Verkehrsmuster der verschiedenen Sensor- und Aktorsignale zu untersuchen. Aus den extrahierten Ergebnissen werden aktuell gültige Anforderungen an Kommunikationssysteme abgeleitet. Der Hauptaugenmerk der Analyse liegt hierbei auf den Zwischenankunftszeiten und den Latenzzeiten einzelner Signale, da hieraus die zeitlichen Anforderungen und Charakteristiken der Anwendung direkt abgeleitet werden können. Die beiden Metriken haben eine unterschiedliche Bedeutung und Aussagekraft. Die Zwischenankunftszeit ist von Bedeutung, wenn es darum geht, den gesamten Prozess zu verstehen. Hierfür ist es immer erforderlich, eine komplette Signalaufzeichnung mit sämtlichen Abhängigkeiten der Signale zu betrachten. Die Latenzzeit ist hingegen entscheidend, wenn Anforderungen für Technologien abgeleitet werden sollen, insbesondere im Bezug auf die Echtzeitfähigkeit. Aus dieser Metrik ist direkt ersichtlich, welche Eigenschaften eine drahtlose Technologie bezüglich oberer Zeitschranken erfüllen muss. Die erzielten Ergebnisse zeigen, dass die höchsten Anforderungen im Bereich von ca. 10 ms (vgl. Tabelle 1) liegen. Wenn der vorhandene Feldbus durch eine drahtlose Technologie ersetzt werden soll, müssten diese garantiert werden. Betrachtet man beispielsweise IEEE 802.11 WLAN [2], ist es möglich, diese Anforderungen unter idealen Bedingungen zu erfüllen, d. h. geringe Auslastung des Übertragungskanals (wenige aktive Stationen) und keine weiteren Interferenzen. Sobald diese Bedingungen jedoch nicht mehr zutreffen, zeigen die Ergebnisse in [11], dass diese hohen Anforderungen mit der derzeitigen WLAN Technologie nicht erfüllt werden können. In zukünftigen Arbeiten werden die erzielten Erkenntnisse zur Entwicklung von realitätsnahen Simulationsmodellen genutzt, im Besonderen zur Erzeugung von Verkehrsgeneratoren, die Verkehrscharakteristiken einer realen Anlage widerspiegeln. Des Weiteren werden die noch nicht ausgewerteten Signale der Anlage bearbeitet. Diese fallen jedoch nur in die Kategorie geringe Anforderungen und sind daher lediglich für die vollständige Charakterisierung der Anlage wichtig. Für die Ableitung von Kommunikationsanforderungen sind diese Signale nicht von Bedeutung.

Danksagungen Wir möchten uns insbesondere bei der Hilscher GmbH für die Bereitstellung der notwendigen Messwerkzeuge und bei Phoenix Contact für den Zugang zur Konzeptmaschine bedanken. Außerdem gilt unser besonderer Dank Prof. Dr. Jürgen Jasperneite für die vielen erkenntnisreichen Diskussionen während der Konzeptionierung und Auswertung der Messungen.

88

R. Just, H. Trsek

Literaturverzeichnis 1. IEEE Std. 802.3-2005 Standard for Local and Metropolitan Area Networks specific requirements. 2005. 26(11):832–843, 1983. 2. IEEE Std. 802.11-2007 Standard for Information technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. 2007. 3. Caida. Cooperative Association for Internet Data Analysis [online], (2009). Verfügbar auf:     4. C. Cseh, M. Janssen, and J. Jasperneite. ATM networks for factory communication. Emerging Technologies and Factory Automation, 1999. Proceedings. ETFA ’99. 1999 7th IEEE International Conference on, pages 797–804, 1999. 5. IEC. Interbus Specification IEC 61158 Type 8, 2002. 6. R. Jain. The Art of Computer Systems Performance Analysis. John Wiley ans Sons, 1991. 7. J. Jasperneite and P. Neumann. Measurement, analysis and modeling of real-time source data traffic in factory communication systems. 3rd IEEE International Workshop on Factory Communication Systems (WFCS ’00), pages 327–333, 2000. 8. R. Langmann. INTERBUS Technologie zur Automation. Fachbuchverlag Leibzig, 1999. 9. ModBus. Modbus User Website [online], (2009). Verfügbar auf:    10. Sercos. Sercos International [online], (2009). Verfügbar auf:     11. H. Trsek, J. Jasperneite, and S. Karanam. A Simulation Case Study of the new IEEE 802.11e HCCA mechanism in Industrial Wireless Networks. In Emerging Technologies and Factory Automation, 2006. ETFA ’06. IEEE Conference on, pages 921–928, Sept. 2006. 12. A. Willig, K. Matheus, and A. Wolisz. Wireless Technology in Industrial Networks. Proceedings of the IEEE, (6):1130–1151, June 2005. 13. R. Zurawski. The Industrial Communication Technology Handbook. CRC Press, 2005.

XML-basierte Produkt- und Prozessdaten für die Leittechnik-Projektierung Miriam Schleipen Fraunhofer IITB Fraunhoferstr.1, 76131 Karlsruhe      

Zusammenfassung. Für die Überwachung und Steuerung hochkomplexer Produktionsprozesse werden Prozessleitsysteme eingesetzt. Ständige Veränderungen zwingen Produktionsbetriebe wandlungsfähig zu sein. Entsprechend muss auch die Technik diese Flexibilität unterstützen. Jede Veränderung des Produktionsprozesses muss eingeplant, die Anlagen neu konfiguriert und projektiert werden. Dabei müssen auch neue Prozessbilder für die Bedien- und Steuerungssysteme erstellt werden. Am Fraunhofer IITB wurde ein Engineering-Framework entwickelt, das das Leitsystem automatisch projektiert und die zugehörige Prozessvisualisierung generiert. In diesem Beitrag wird das Modul vorgestellt, dass die Prozessabbilder erstellt. Neben der Visualisierung von Anlagen werden auch laufende Prozesse und bearbeitete Produkte dargestellt. So können beispielsweise Identsysteme mit der Leittechnik gekoppelt werden.

1 Einleitung Um alle am Produktionsprozess beteiligten ’Dinge’ elektronisch beschreiben zu können, werden diese in der Praxis in drei Kategorien aufgeteilt: Ressourcen, Produkte und Prozesse. Leitsysteme fokussieren normalerweise auf die Ressourcen. Ein Leitsystem bezeichnet in diesem Zusammenhang ein komplexes zentrales oder dezentrales ITSystem zur Erfassung, Aggregation/Verdichtung und Verarbeitung von Prozesssignalen und -werten in Realzeit. Es wirkt entweder automatisiert oder durch Benutzereingriffe steuernd auf Fertigungs- und Montageprozesse ein. In Anlehnung an die Definition von Polke [1] hat ein Leitsystem die Aufgabe, die Mitarbeiter in der Produktion bei der Führung ihrer Anlagen und der Steuerung und Überwachung der Produktionsprozesse zu unterstützen. Zur automatisierten Projektierung der Leittechnik wurde am Fraunhofer IITB ein prototypisches Engineering-Framework basierend auf standardisierter Kommunikation und Verarbeitung mittels OPC-Unified Architecture (OPC-UA) und einem standardisierten Datenformat – Computer Aided Engineering eXchange (CAEX) – entwickelt, das sowohl das Leitsystem automatisch projektiert als auch die zugehörigen Prozessvisualisierungen generiert. Die Kombination aus beiden Standards in einem Framework unterstützt die einzelnen Stärken und schafft neue Möglichkeiten zur Automatisierung der Automatisierung. Mit der Visualisierungskomponente des Frameworks können die Prozessbilder automatisch generiert werden. Dadurch bekommen die Bilder ein einheitliches und immer

90

M. Schleipen

aktuelles Aussehen. Zusätzlich zur ’normalen’ Ressourcenvisualisierung in der Leittechnik werden in dieser Komponente ebenfalls Produkte und Prozesse visualisiert, die am Produktionsprozess beteiligt sind. Die Bewegung der produzierten Produkte und Veränderung der laufenden Prozesse (Aktivitäten) werden auf Grund von dynamisch veränderten CAEX-Daten visualisiert. Die Struktur von Elementen, Anlagen und Produkten innerhalb der Bilder wird dynamisch aufgebaut. Die Zuordnung der Produkte und Prozesse zu einer Ressource (Anlage) erfolgt ebenso dynamisch. Als Anwendungsbeispiel soll eine für das Engineering-Framework gewählte Beispielanlage verwendet werden. Die Anlage besteht aus einem Drehtisch (DT1), ein- und auslaufender Fördertechnik (Transportbänder eins (TB1) und zwei (TB2)) und einer Teststation (TS1). Dieses Beispiel soll um Produkt- und Prozessinformationen erweitert werden. Abb. 1 stellt die Testanlage und den Pfad mit einzelnen Stationen, entlang dessen die Produkte während der Bearbeitung befördert werden, dar.

Abb. 1: Grundbild des Anwendungsbeispiels

Durch die automatische Bildgenerierung wird dem Benutzer eine bessere Kontrolle des Produktionsprozesses ermöglicht. Für die Darstellung von Produktbewegungen und Veränderungen der laufenden Prozesse muss in regelmäßigen Zeitabständen ein Abbild der aktuellen Produktionssituation erstellt werden. Die Veränderungen der Prozesse und Produktpositionen müssen für die Leittechnik nicht in Echtzeit dargestellt werden. Für die Aktualisierung von Produkt- und Prozessdarstellungen in der Prozessvisualisierung ist eine Taktzeit von fünf Sekunden (maximal zehn Sekunden) ausreichend. Die Prozesssignale werden aber weiterhin in Echtzeit visualisiert. Die abgebildeten Informationen müssen möglichst übersichtlich gestaltet werden und auch von ungeübten Benutzern intuitiv interpretierbar sein.

2 Leitsystem Engineering Framework Zur automatisierten Projektierung (siehe auch [2]) verwendet das IITB als standardisiertes Datenformat das herstellerunabhängige XML-basierte Austauschformat CAEX [3].

XML-basierte Produkt- und Prozessdaten für die Leittechnik-Projektierung

91

Es wurde als werkzeugneutrales, objektorientiertes Datenformat zur Speicherung von hierarchischen Anlageninformationen entwickelt. In [4] und [5] werden die Struktur und die Elemente von CAEX näher beschrieben. Obwohl CAEX für die Verfahrenstechnik entwickelt wurde, wurde in [6] gezeigt, wie sich das CAEX-Modell für den Austausch von statischen Daten in einem Produktionsleitsystem wie Provis.Agent® eignet und wie es dafür angepasst und verwendet wurde. Als Kommunikationsstandard nutzt das IITB die OPC Unified Architecture [7]. Liegt eine CAEX-Anlagen-Beschreibung aus einem Planungssystem, z.B. einem E-Planungssystem, vor (vergleiche Abb. 2), wird sie per OPC-UA an das Änderungsmanagement des Leitsystems übermittelt, das nun die Aufgabe der Projektierung und Prozessbildgenerierung erledigt. Im Anwendungsbeispiel werden die Anlage und ihre Fähigkeiten mittels CAEX beschrieben. Das entstandene CAEX-Dokument enthält Informationen zur Aufbaustruktur und Topologie der Anlagenkomponenten, die EA-Anbindung zum Prozess und die visualisierungsrelevanten Informationen. Das CAEX-Dokument wird in projektierungsund visualisierungsrelevante Anteile aufgeteilt (siehe linker und rechter Pfad Abb. 2) und die Anteile jeweils an die Projektierungs- und Visualisierungskomponente der ProVis-Production-Suite weitergeleitet. Aus dem Visualisierungsanteil werden die Prozessbilder erzeugt [8]. Der Projektierungsteil wird in eine Datenbank eingelesen. Aus diesen Daten kann das System die EA- und Anlagenprojektierung für das Prozessabbild des Laufzeitsystems generieren (siehe [6]). Mit dem Anwendungsbeispiel wird gezeigt, dass es möglich ist, mit Hilfe von CAEX Daten abzuspeichern und für andere Systeme zugänglich zu machen. Diese Erkenntnis öffnet neue Anwendungsmöglichkeiten für die bestehenden Systeme. Mit der Visualisierungskomponente können die Prozessbilder automatisch generiert werden. Dadurch bekommen die Bilder ein einheitliches und immer aktuelles Aussehen.

3 Das Datenformat CAEX Der Vorteil der CAEX-Definition als eine neutrale Beschreibungssprache gegenüber den früheren Versuchen eine gemeinsame Standardschnittstelle zu schaffen sind ihre Metamodellierungstechniken. Beim Einsatz einer standardisierten Schnittstelle werden die Daten in für alle Kommunikationspartner bekannten Strukturen (beziehungsweise in der vereinbarten Art und Weise) ausgetauscht. Statt die verallgemeinerten Strukturen zu nutzen definiert CAEX eigene Modellstrukturen und verwaltet diese in Klassenbibliotheken. Während des Datenaustauschs können die CAEX-Bibliotheken zusammen mit den Daten an andere Systeme versendet werden. Alle Systeme, die das CAEX-Datenmodell unterstützen, sind in der Lage, die Strukturinformationen aus den Bibliotheken auszulesen und die empfangenen Daten zu interpretieren. Somit wird das Problem der Komplexität der herstellerspezifischen Aspekte vereinfacht. Das CAEX-Datenmodell ist auf den obersten Ebene in vier Bereiche unterteilt: drei Bibliotheken – ’InterfaceClassLib’, ’RoleClassLib’ und ’SystemUnitClassLib’ – und die Abbildung der Anlagenstruktur ’SystemHierarchy’. Die Bibliotheken stellen eine Sammlung von Konstruktdefinitionen dar. Sie legen die Struktur der Objekte fest. In der ’SystemHierarchy’ wird die tatsächliche Anlagenzusammensetzung modelliert. Für die

92

M. Schleipen CAEX Anlage/SPS liefert CAEX-Datei mit: Projektierungsdaten - Anlagen - EA Visualisierungsdaten - EA - Topologie

Validierung der CAEXDatei

Webservice

XSLTTransformation

Projektierungsrelevante Daten Direkt einlesen

Vorschrift zur - Aufteilung - leitsystemspezifischen Zuordnung

Layoutmanager Visualisierungsrelevante Daten Prozessführungsbilder generieren mit individueller Anpassung durch Layoutmanager

Angabe der Prioritäten und Präferenzen bei der Visualisierung von Anlagen

Projektierungsdatenbank

OPC-UA-Client-Server-Architektur

Abb. 2: Automatische Leitsystemprojektierung am Beispiel von ProVis.Agent®

Anlagenabbildung werden die Instanzen der in den Bibliotheken vordefinierten Modelle verwendet und ihnen aktuelle Parameterwerte zugeordnet. Die ’InterfaceClassLib’ ist die Bibliothek der Schnittstellenklassen. Eine Klasse definiert einen Schnittstellentyp, den Verbindungspunkt zweier Elemente. Über die implementierten Schnittstellen können zwei Objekte miteinander verbunden werden. Die Schnittstelle bestimmt die Relationsart und die semantische Bedeutung dieser Verbindung. Zum Beispiel die Verbindung einer Anlagenkomponente ’Transportband’ mit dem Prozess ’Transportieren’ über die ’prozesslink’-Schnittstelle, ergibt die semantische Bedeutung: ’Transportband führt den Prozess Transportieren aus’. Die Klasse, die das Objekt ’Transportieren’ definiert muss ebenso wie die Anlagenklasse die ’prozesslink’-Schnittstelle implementieren. In der ’RoleClassLib’ werden die funktionalen Rollen der Objekte beschrieben. Die Rollen setzten die ’ich bin ein...’-Beziehung um. Zum Beispiel kann dies ein Transportband sein. Die Rolle gibt keine Informationen über den inneren Aufbau eines Elements, sie bestimmt nur seine Art und das Verhalten. Für diesen Zweck kann eine Rolle Schnittstellen und allgemeine Attribute besitzen. Durch diese Abstraktion kann zum Beispiel allen Anlagen, die Transportbänder sind, ein gemeinsames grafisches Objekt

XML-basierte Produkt- und Prozessdaten für die Leittechnik-Projektierung

93

für die Visualisierung zugeordnet werden. Dadurch können alle Transportbänder visualisiert werden, ohne dass die genauen Strukturinformationen der einzelnen Anlagen bekannt sind. In der ’SystemUnitClassLib’ werden die Schablonen für die einzelnen Systemeinheiten definiert. Ähnlich den Klassen in der objektorientierten Programmierung legen sie die innere Struktur und die vorhandenen Attribute der Elemente fest. Eine neue Strukturbeschreibung wird mit dem ’SystemUnit’-Knoten eingeführt. Jede Struktur kann hierarchisch aufgebaut werden und weitere, bereits vordefinierte Strukturen, als Teilelemente verwenden. Auf diese Weise kann ein Anlagenelement zum Beispiel ein eigenes Attribut ’Name’ definieren und aus einem Unterelement ’Rechteck’ bestehen. Die Struktur des Rechteck-Elements wird in der separaten Rechteck-Klasse definiert, und legt beispielweise die für die Visualisierung notwendigen Attribute wie X-/YKoordinaten fest. Des Weiteren kann das Anlagenelement die in der Rollen-Bibliothek definierte Rolle ’Transportband’ implementieren. Durch die Rollenzuordnung bekommt das Element eventuell weitere rollenspezifischen Attribute und Schnittstellen, die seine Interaktionsmöglichkeiten mit anderen Elementen bestimmen. Das Ergebnis dieser Definition wäre ein Transportband, das einen Namen hat, als Rechteck dargestellt wird und Schnittstellen zu Prozessen und Produkten besitzt. Die tatsächlichen Exemplare (Instanzen) der in den Bibliotheken definierten Klassen werden in der ’SystemHierarchy’ erstellt. Hier werden den Klasseninstanzen die konkreten Werte zugewiesen und die Elemente miteinander verknüpft. Somit repräsentiert die ’SystemHierarchy’ ein konkretes System. Diese Daten können gespeichert oder an ein anderes System, zum Beispiel die Visualisierung, weitergeleitet werden. In Verbindung mit den Bibliotheken wird den Daten die semantische Bedeutung hinzugefügt, so dass auch ein fremdes System diese Informationen interpretieren kann.

4 Produkt-Prozess-Visualisierung – Konzept und Umsetzung Das Engineering-Framework unterteilt alle vorhandenen Systemelemente in drei Kategorien – Produkt, Prozess und Ressource (PPR-Konzept). Unter Produkten werden alle Produkte und Produktbauteile verstanden, zu Prozessen werden alle möglichen Aktivitäten gezählt und Ressourcen vereinen Anlagen, Arbeiter, Software und so weiter. Durch diese Dreiteilung wird den Systemelementen zusätzlich eine semantische Bedeutung zugeordnet – ’ich bin ein Produkt’, ’ich bin eine Ressource’ oder ’ich bin ein Prozess’. Die einzelnen Elementarten können miteinander verknüpft werden, wobei die Ressourcen das zentrale Glied in diesem Modell bilden: Ressourcen führen Prozesse aus und Ressourcen bearbeiten Produkte. Im Rahmen des Engineering-Frameworks wird das PPR-Konzept in das CAEX-Datenmodell integriert. Für die Aufteilung sind die Bereiche ’RoleClassLib’, ’SystemUnitClassLib’ und ’SystemHierarchy’ des CAEX-Modells relevant. In diesen Bereichen können Strukturen aller drei Arten – Produkte, Prozesse und Ressourcen – definiert beziehungsweise angewendet werden. In der ’InterfaceClassLib’ werden Schnittstellen definiert, die allen Elementarten zur Verfügung stehen, aus diesem Grund wird hier keine Unterteilung vorgenommen. Die Aufteilung geschieht jeweils auf oberster Ebene, vor der Definition beziehungsweise Verwendung der einzelnen Elemente. Dadurch er-

94

M. Schleipen

ben alle unterhalb definierten Elemente die semantische Bedeutung des gemeinsamen Oberknotens. Zum Beispiel sind alle Strukturdefinitionen unter dem Pfad ’SystemUnitClassLib/Ressourcen’ Ressourcenmodelle. In der ’InterfaceClassLib’ sind drei Schnittstellen vordefiniert: ’Produktlink’, ’Prozesslink’, und ’Anlagentopologielink’. Damit zwei Elemente miteinander verknüpft werden können, müssen beide die jeweilige Schnittstelle (Verbindungsart) implementieren. Mit einem ’Produktlink’ kann beispielweise eine Ressource mit einem Produkt verbunden werden. Und mit einem ’Anlagentopologielink’ lassen sich zwei Teilanlagen (Ressourcen) in einen topologischen Zusammenhang setzen. Abbildung 3 stellt eine Beispielsituation dar, in der das Transportband TB1 die Karosse 123 transportiert und topologisch mit dem Drehtisch DT1 verbunden ist. Schnittstellen werden den Elementen nicht direkt, sondern durch die funktionalen Rollen zugeordnet. Rollen werden in der ’RoleClassLib’ definiert und bestimmen einerseits die Zugehörigkeit eines Elements zu einer Klassenart, wie zum Beispiel Transportband oder Drehtisch, anderseits bestimmen sie durch die Implementierung der Schnittstellen die Kommunikationsmöglichkeiten mit anderen Elementen. Auf oberster Ebene werden alle Rollen in Produkt-, Prozess- und Ressourcerollen aufgeteilt. Mit jeder tieferen Ebene werden die Rolleneigenschaften weiter spezifiziert. Dieses Verhalten entspricht dem Vererbungskonzept in der objektorientierten Programmierung. Durch die Rollenzuweisung erhält beispielweise das Element ’TB1’ (Abb. 3) folgende Informationen: ’Ich bin eine Ressource und zwar ein Transportband. Ich kann Prozesse ausführen, Produkte verarbeiten und Teil einer Anlagentopologie sein.’ Für die Beschreibung der Produkte existiert derzeit nur eine Rolle ’Produkt’. Die Prozesse werden semantisch ebenfalls durch die Zuweisung der Rolle ’Prozess’ gekennzeichnet. Die Rolle ’Ressource’ besitzt weitere Unterklassen: ’Transportband’, ’Drehtisch’, ’Teststation’ und ’OPC-Server’. Die Strukturmodelle der einzelnen Elemente werden in Klassen der ’SystemUnitClassLib’ definiert. Der Knoten ’SystemUnitClass’ leitet eine neue Strukturdefinition (eine neue Klasse) ein. In einem Strukturmodell werden Attribute definiert, eine Rolle zugeordnet und bereits vordefinierte ’SystemUnit’-Klassen als Teilelemente referenziert. Somit können beliebige Strukturen aus Teilelementen gebildet werden.

- Produkt Transportiere

Karosse

- Prozess - Ressource - Produktlink

DT1

TB1

...

- Prozesslink - Anlagentopologielink

Abb. 3: Verknüpfung der Elemente an Hand der umgesetzten Schnittstellen

Die Bildgenerierung soll in das allgemeine Konzept des Engineering-Frameworks passen und den zuvor definierten und umgesetzten Konzepten nicht entgegenwirken. Ebenso soll die Allgemeingültigkeit des CAEX-Modells durch die Bildgenerierung

XML-basierte Produkt- und Prozessdaten für die Leittechnik-Projektierung

95

nicht eingeschränkt werden. Die Struktur der Elemente, wie zum Beispiel Produkte oder Anlagen, muss daher dynamisch, an Hand in CAEX vordefinierter Modelle, aufgebaut werden. Die Verknüpfungen zwischen Anlagen, Prozessen und Produkten müssen ebenfalls dynamisch geschaffen werden. Durch diesen Ansatz bleiben die neue Bildgenerierung und das Engineering-Framework voneinander unabhängig. Da die Leittechnik nur abstrahierte Informationen aus dem Produktionsprozess visualisiert, müssen Produkte wie Prozesse dort nicht vollständig dargestellt werden. Es reicht für diesen Anwendungszweck aus, wenn Produkte als Bitmap an diskreten Positionen der Ressourcen visualisiert werden können. Prozessinformationen sind in Textform mit optional aufrufbaren Zusatzinformationen ausreichend. Wichtig ist zusätzlich die Darstellung der Prozessrichtung bzw. der Prozessausführungsrichtung, da sie als Hinweis bei der Erkennung von eventuellen Fehlern im Produktionsprozess hilfreich sein kann. Bei der Visualisierung der Ressourcen müssen neben den grafischen Elementen auch andere Informationen, zum Beispiel der Ressourcen- oder Prozessname, dargestellt werden. Es kann nicht ausgeschlossen werden, dass in Zukunft auch weitere Informationen hinzukommen. Außerdem können einige Anlagenkomponenten eine größere Anzahl an visualisierungsrelevanten Informationen besitzen als andere. Ein Beispiel dafür ist wiederum der Prozessname. Wenn eine Ressource gerade keinen Prozess ausführt, wird auch kein Prozessname auf dieser Ressource abgebildet. Es muss also eine einheitliche Lösung gefunden werden, die Ressourceninformationen darzustellen. Die Ressourcen- und Prozessnamen werden in einem Textfeld dargestellt. Damit die abgebildeten Informationen die neben der Ressource platzierten Bildelemente nicht verdecken, müssen sie über der Ressource positioniert werden. Der Bereich in der Ressourcen-Mitte (rechts, links oder mittig) wird oft durch die grafischen Repräsentationen der bearbeiteten Produkten verdeckt. Die rechtsbündige Ausrichtung ist allgemein schlecht geeignet, da der Textfluss in der deutschen und englischen Sprache von links nach rechts erfolgt. Somit würde der Text-Anfangspunkt sich in Abhängigkeit von der Wortlänge immer weiter nach links verschieben und bei jeder Ressource an einer anderen Position beginnen. Im Extremfall kann er sogar auf einer ’falschen’ Ressource, links neben der eigentlichen Ressource, landen. Die Positionierung im unteren Teil des Elements ist ebenso ungeeignet, da Texte standardmäßig von oben nach unten wachsen. Daher ist die obere linke Ecke als Aufhängungspunkt am besten geeignet. Außerdem werden die meisten grafischen Objekte in ProVis.Visu® an Hand der oberen linken Ecke positioniert. Dadurch müssen keine beziehungsweise weniger zusätzliche Koordinatentransformationen gemacht werden, um die Textfelder zu positionieren. Ein weiteres Problem ist die Darstellung der Texte. Die Darstellung der Teilanlagen kann sehr stark in Form, Farbe und Anzahl der grafischen Elemente variieren. Die Beschriftung sollte aber auf jeder beliebigen Form und vor jedem Hintergrund gut lesbar sein. Da nicht jede einzelne Farb- und Formvariation der darunterliegenden Ressource berücksichtigt werden kann, werden die Texte vor einem neutralen Hintergrund, in Form von Informationsleisten, dargestellt. Abhängig von den Informationen der Ressource, wird die entsprechende Leiste dargestellt oder komplett ausgeblendet. Für die Farbauswahl stehen alle Farben außer rot, gelb, grün und hellgrau zur Verfügung, da diese eine besondere Bedeutung in ProVis.Visu® haben. Beispielweise zeigt grün, dass

96

M. Schleipen

der Variablenwert im Gültigkeitsbereich liegt. Rot, im Gegenteil, weist auf ein Problem hin. Für die Darstellung der Informationsleisten wurde weißer Text vor dunkelgrauem Hintergrund gewählt. In dieser Farbkombination ist der Text deutlich lesbar. Insgesamt wurden zwei Informationsleisten definiert: die Ressourcenleiste und die Prozessleiste. In der Ressourcenleiste wird der Ressourcenname abgebildet. Diese Leiste wird auf jeder Ressource dargestellt, da der Name ein Pflichtattribut ist und bei jeder Ressource vorhanden ist. Die Prozessleiste zeigt den gerade auf der Ressource ausgeführten Prozess in Form des Prozessnamens an. Sie wird nur dargestellt, wenn die Ressource tatsächlich einen Prozess ausführt. Außer den Namen können Prozesselemente auch über weitere Informationen verfügen. Derzeit besitzen Ressourcen und Prozesse das Attribut Beschreibung. Angaben dieser Art geben zusätzliche Auskünfte. Sie müssen nur bei Bedarf angezeigt werden. Die Produkte haben wie die Ressourcen einen Namen (Bezeichnung) und eine Beschreibung. Eventuell können auch weitere Informationen, wie beispielsweise die ID hinzukommen. Im Fall von Produkten, können die Informationen nicht in einer Leiste dargestellt werden. Die Objekte, die Produkte respräsentieren, sind meistens zu klein und würden von den Leisten verdeckt. Als Lösung wird die Tooltiptext-Eigenschaft der grafischen Elemente für alle zusätzlichen Angaben verwendet. Die Tooltiptexte der Ressourcen werden beim Ressourcennamen (Ressourcenleiste) dargestellt. Sie beanspruchen einen relativ großen Teil der Bildfläche. Der Tooltiptext an den Objekten selbst hätte eher eine störende als helfende Wirkung. Die Prozesse werden im Bild nur durch ihre Namen repräsentiert. Daher wird der Tooltiptext der Prozessleiste verwendet Im Fall von Produkten werden die Tooltiptexte direkt auf die grafischen Elemente gesetzt, die das Produkt repräsentieren. Im Prozessabbild des Anwendungsbeispiels ist der Prozessverlauf nicht ohne Zusatzwissen erkennbar. Es ist beispielsweise nicht erkennbar, ob die Produkte der Anlage von oben über das Transportband TB2 oder von rechts über das Transportband TB1 zugeführt werden. Damit der Anwender den Prozessausschnitt der Realität zuordnen kann, wird ein weiteres Attribut ’Richtung’ für Ressourcendefinitionen eingeführt. Mit diesem Attribut soll die Ausführungsrichtung des Prozesses auf der Anlage dargestellt werden. Visuell kann die Richtung in Form eines Pfeils abgebildet werden. Für das Attribut Richtung wurden die in Abb. 4 dargestellten Werte definiert.

Richtung

Wert

Symbol

Nicht angezeigt

0

-

Nach links

1

Nach rechts

2

Aufwärts

3

Abwärts

4

Abb. 4: Richtungsattribut

XML-basierte Produkt- und Prozessdaten für die Leittechnik-Projektierung

97

Obwohl die Richtung ein Attribut der Ressource ist, beschreibt sie die Verknüpfung der Ressource mit dem Prozess. Wenn die Ressource aktuell keinen Prozess ausführt, hat sie auch keine Ausführungsrichtung. Aus diesem Grund wird die Richtung semantisch mit dem Prozess verknüpft und in der Prozessleiste visualisiert (Abb. 5).

Abb. 5: Darstellung der Ressourcen mit Ressourcen- und Prozessleiste

5 Zusammenfassung und Ausblick Für die automatisierte Produkt- und Prozessvisualisierung wurde zusammenfassend folgendes Konzept erstellt: Für die Visualisierung der Objekte sind grafische Basiselemente vordefiniert. Ein Objekt kann aus einem oder mehreren grafischen Elementen zusammengesetzt werden. Ressourceneigenschaften werden in der Ressourcenleiste und als deren Tooltiptext dargestellt. Das Attribut Richtung wird zusammen mit dem ausgeführten Prozess in der Prozessleiste der Ressource dargestellt. Es werden keine leeren Informationsleisten angezeigt. Dasselbe gilt für den Prozess. In der Prozessleiste der prozessausführenden Ressource wird der Prozessname dargestellt, die Beschreibung wird als Tooltiptext der Leiste dargestellt. Die Ressourcen- und Prozessleiste werden in der oberen linken Ecke der Ressource positioniert. Produkteigenschaften werden zusammengefasst und als Tooltiptext des gesamten Produkt-Grafikelements dargestellt.

(a)

(b)

Abb. 6: Produkt-Prozess-Visualisierung zum Zeitpunkt t0 (links) und Zeitpunkt t1 > t0 (rechts)

98

M. Schleipen

Abb. 6 (links) zeigt ein generiertes Prozessabbild zum Zeitpunkt t0 . Die Karosse kar0011 befindet sich zu diesem Zeitpunkt auf dem Transportband TB1 (im Zustand ’Transportieren nach links’) auf dem Weg zur Teststation TS1. Eine weitere, bereits geprüfte Karosse befindet sich auf dem Drehtisch DT1 im Zustand ’Drehen-Umsetzen nach rechts’. Abb. 6 (rechts) zeigt ein generiertes Prozessabbild zum Zeitpunkt t1 > t0 . Die Karosse kar0011 befindet sich jetzt an der Teststation TS1 (im Zustand ’Prüfen’) und wird gerade geprüft. Die weitere, bereits geprüfte Karosse befindet sich jetzt auf dem Transportband TB2 (im Zustand ’Transportieren nach oben’). Auf dem Transportband TB1 ist eine dritte Karosse in den Produktionsprozess eingetreten.

Literaturverzeichnis 1. Polke, M (edit.): Prozeßleittechnik. Oldenbourg, 1994. 2. Sauer O, Ebel M: Plugand-work von Produktionsanlagen und übergeordneter Software. Aktuelle Trends in der Softwareforschung, Tagungsband zum do it.software-forschungstag 2007, Heidelberg, dpunkt.verlag, 2007. 3. IEC 62424 - Ed. 1.0: Specification for Representation of process control engineering re-quests in P&I Diagrams and for data exchange between P&ID tools and PCECAE tools. Text English, 2008. 4. Drath R, Fedai M: CAEX - ein neutrales Datenaustauschformat für Anlagendaten - Teil 1. Oldenburg, München, atp - Automatisierungs-technische Praxis (46) 2004, 2: 52–56. 5. Drath R, Fedai M: CAEX - ein neutrales Datenaustauschformat für Anlagendaten - Teil 2. Oldenburg, München, atp - Automatisierungstechnische Praxis (46) 2004, 3: 20–27. 6. Ebel M, Drath R, Sauer O: Automatische Projektierung eines Produktionsleitsystem mit Hilfe des Standarddatenaustauschformats CAEX. Oldenburg, München, atp - Automatisierungstechnische Praxis (50), 5.2008, pp.40–47. 7. OPC Foundation: OPC-UA.    , 2009. 8. Schleipen M, Schick K: Self-configuring visualization of a production monitoring and control system. CIRP International Conference on Intelligent Computation in Manufacturing Engineering - CIRP ICME ’08, Naples, Italy, 23–25 July 2008.

Leicht konfigurierbare Hardware-Abstraktionsschicht für flexible Automatisierung Uwe Schmidtmann, Gerhard Kreutz, Matthias Barkhoff, Kristian Virkus, Tobias Stöckmann und Marcel Jovic Institut für Informatik, Automatisierungstechnik und Robotik der Fachhochschule Emden/Leer, 26723 Emden 

    

 

Zusammenfassung. Energie- und Materialverbrauch, Qualität sowie Durchsatz werden heutzutage als die Parameter angesehen, die die Wirtschaftlichkeit einer Produktion wesentlich bestimmen. Sie zu optimieren ist daher eine zentrale Aufgabe der Entwicklung zukünftiger Fertigungsanlagen. Dieses Ziel lässt sich erreichen, indem der gesamte Fertigungsprozess über alle Schichten der Automatisierungspyramide (ERP, MES, Feld) flexibel und rekonfigurierbar gestaltet wird. Mit Hilfe des aktuellen Forschungsprojektes LK3 S wird eine Agentenplattform entwickelt, die diese Optimierung und Flexibilität ermöglichen soll. Dieser Beitrag diskutiert das Design und die Entwicklung einer Hardware-Abstraktionsschicht der Feldebene, die alle von der Agentenplattform benötigten Dienste bereitstellt und die die Verbindung zwischen Arbeitsaufträgen und Automatisierungsprimitiven herstellt, z. B. die Montage eines Reifens durch einen Roboter. Automatisierungsprimitiven bestehen aus einer Folge von elementaren Operationen, womit sie auf unterster Ebene unter Einhaltung aller Echtzeitvorgaben parallelisiert werden können. Sie haben eine ähnliche Bedeutung wie Mikrocode für CPUs. Selbst zur Laufzeit können neue Automatisierungsprimitiven in der Feldebene definiert, übertragen, aktiviert und entfernt werden.

1 Einleitung Es werden zunehmend flexiblere Produktionsumgebungen benötigt, da der Markt zunehmend nach individuell gestalteten und angepassten Produkten verlangt (cf. Committee on Visionary Manufacturing Challenges [9], EU [1, 2] und weitere). Die heute üblichen Produktionssysteme unterstützen jedoch meist nur einen fest programmierten Satz Fertigungsprogramme, die die Freiheiten bei der individuellen Produktgestaltung und des Materialflusses innerhalb der Produktionsumgebung stark begrenzen. Den wachsenden Anforderungen kann nur mit einer intelligenten Steuerung begegnet werden, wie sie z. B. durch Agentensysteme realisiert werden kann. Die aktuelle Bedeutung von Agentensystemen in der Fertigung spiegelt sich auch in den vielzähligen EU-Projekten und Veröffentlichungen zu diesem Thema wider. In den Veröffentlichungen zu Plant Automation BAsed on DIstributed Systems (PABADIS) [6, 8, 10] und zu Holonic Manufacturing Systems (HMS) [3] wurden bereits Multiagentensysteme in der Fertigung beschrieben und evaluiert. Das Projekt Service-Oriented Crosslayer infRAstructure for Distributed smart Embedded deviceS (SOCRADES) [4, 5, 11] führt zudem noch eine serviceorientierte Architektur zur Nutzung von Automatisierungsdiensten ein.

100

U. Schmidtmann et al.

Die Fachhochschule Emden/Leer arbeitet im Rahmen des LK3 S-Projektes1 an dieser Problemstellung und evaluiert den neuen Ansatz anhand der Digitalen Fabrik als beispielhafte Fabrikumgebung. Bei der Digitalen Fabrik handelt es sich um ein reales Automatisierungsmodell zur diskreten Fertigung. Es besitzt 295 digitale und analoge Ein-/Ausgaben. Zudem ist sie mit Transportbändern ausgestattet, über die Bauteilträger transportiert werden können. Des Weiteren kommen in der Anlage RFID-Tags, ein Hochregallager, verschiedene Roboter und viele weitere Komponenten zum Einsatz. Die Digitale Fabrik ist in sieben logische Einheiten unterteilt: das Verteilsystem, das Hochregallager, der Warenein-/ausgang sowie vier Arbeitsplätze (siehe Abb. 1 links). Die meisten Sensoren und Aktoren des Automatisierungsmodells sind über PROFIBUS und CANopen ansprechbar. Es kommen verschiedene High-Level-Protokolle bei der Kommunikation zum Einsatz, wie z. B. Lenzes drivecom- (Antriebe) und Baumers ident-Protokoll (RFID).

Abb. 1: links: schematische Darstellung der Digitalen Fabrik, rechts: Architektur mit Agent, Operator und Stub.

1

Leicht Konfigurierbare Komponenten Kollaborativer Systeme

Leicht konfigurierbarer HAL

101

Beim ersten Versuch, die Digitale Fabrik mit flexiblem Material-Routing zu automatisieren, wurden SPSen eingesetzt. Sie waren mit einem PC-basierten MES verbunden. Zudem wurde ein Agentensystem entwickelt, das sich jedoch als zu unflexibel erwiesen hat. Der Datenaustausch zwischen SPSen und dem jeweils verbundenen PC hat sich als Flaschenhals erwiesen. Die Aufgabe der Wegfindung für den Transport von Bauteilträgern über mehrere Arbeitsplätze hinweg ist so komplex, dass ein Cluster aus Industrie-PCs eingerichtet wurde. Durch diesen Aufbau sollen der zuvor bemängelte Flaschenhals beseitigt und die Flexibilität erhöht werden. Eine Analyse der Transportaufgaben zeigte, dass sie in wesentlich einfachere Aufgaben zerlegt werden können. Die Transportbänder besitzen nur eine feste Anzahl Haltepunkte, an denen Bauteilträger angehalten werden können. Eine aufgabenorientierte Abstraktionsschicht sollte Befehle wie „bewege Bauteilträger von A nach B“ zur Verfügung stellen und in elementare Schritte zur Steuerung der Hardware umsetzen. Diese elementaren Schritte werden in sogenannten Mikrocodes zusammengefasst, die in einer XML-Konfigurationsdatei definiert sind. Komplexe Transportaufgaben bestehen aus einer Folge einfacher Transportaufgaben zwischen benachbarten Haltepunkten. Damit Hardwarezugriffe technologieunabhängig bleiben, gibt es eine weitere Abstraktionsschicht, die Symbole zum Zugriff auf Sensoren und Aktoren verwenden. Der Ansatz folgt dem Motto divide et impera. Dieser Beitrag ist wie folgt strukturiert: Nach der Einleitung folgt mit Abschnitt 2 die Architekturbeschreibung des entwickelten Systems mit näherer Betrachtung der Software-Komponenten, aus denen es besteht. Abschnitt 3 stellt die Implementation der Hardware-Abstraktionsschicht und die umgesetzten Konzepte zur Ausführung des Hardwarezugriffs dar, während Abschnitt 4 diesen Ansatz und die erzielten Ergebnisse zusammenfasst und einen Ausblick auf zukünftige Arbeiten gibt.

2 Architektur Der Lösungsansatz des LK3 S-Agentensystems ist es, eine Architektur zu schaffen, die jeder Schicht eine abstrakte Sicht und Kontrolle über ihre unterliegende Schicht bereitstellt (Abb. 1 rechts). Es gibt verschiedene Agententypen: Ein Agent hat eine oder mehrere Rollen im System. Rollen beherrschen verschiedene Aufgaben wie Lagerverwaltung, Durchführung des Produktionsvorgangs und Materialbestellung. Die Hauptaufgabe der Agenten ist es, den Produktionsvorgang zu steuern, zu beobachten und zu optimieren. Sie benötigen künstliche Intelligenz um Optimierung, Kommunikation mit anderen Agenten und die Auswertung von Statistiken aus einer Datenbank umzusetzen. Agenten, die Hardware steuern müssen, erlauben einer beliebigen Anzahl Handlangern ihnen, ihre Dienste zur Verfügung zu stellen. Um flexibel auf Kundenwünsche zu reagieren, kann ein Agent mit einem Auftrag an einen Handlanger auch Parameter übergeben, die z. B. zur exakten Positionierung von unterschiedlichen Anbauteilen benötigt werden. Bevor ein Auftrag an einen Handlanger vergeben wird, kann ein Agent zunächst Angebote bezüglich Kosten und Energieverbrauch von allen Handlangern einholen.

102

U. Schmidtmann et al.

In dem LK3 S-Lösungsansatz werden Handlanger als Operatoren bezeichnet. Sie können als eingeschränkte Agenten angesehen werden, da sie nur dann aktiv werden, wenn sie ausdrücklich dazu aufgefordert werden. Dennoch können sie über eine gewisse künstliche Intelligenz verfügen, die auf ihre Aufgaben begrenzt ist. Beispiel: Ein Agent, der ein Lagersystem verwaltet, braucht keine detaillierten Informationen über die genaue Struktur und den Aufbau des Lagers. Ein Lageroperator hingegen muss Kenntnis darüber besitzen, um Materialein- und auslagerungen optimal planen und ausführen zu können. Operatoren bieten aufgabenorientierte Dienste an wie „bewege Bauteilträger von A nach B“. Diese Dienste werden in Klassen unterteilt, z. B. Transportieren und Wiegen. Operatoren melden sich bei Agenten an und teilen ihnen mit, welche Dienste sie bereitstellen. Die Kommunikation basiert auf einem TCP/IP-Textprotokoll, über das XML-kodierte Daten ausgetauscht werden. Zur Vereinheitlichung der OperatorKommunikation existiert ein Grundgerüst, welches eine Schnittstelle bereitstellt, die der Entwickler implementieren muss, um eine neue Operatorklasse zu erstellen. Dies ermöglicht eine schnelle und einfache Erweiterung des Systems. Da Operatoren mit unterschiedlicher Hardware ähnliche Aufgaben bearbeiten sollen, ist es im Sinne der Rekonfigurierbarkeit, eine weitere Schicht einzuführen, die die Hardware abstrahiert und auf der die Operatoren aufsetzen. Diese Abstraktion wird durch den sogenannten Stub erzielt. Operatoren können sich beliebig oft zu ihnen verbinden. Die Kommunikation mit einzelnen Aktoren und Sensoren erfolgt über die Wandlung von symbolischen Namen in echte Hardwareadressen, entsprechend der XMLKonfiguration des Stubs, welche alle Details der unterliegenden Feldbusse beschreibt, wie Bitmasken und verwendete Protokolle. Dies entkoppelt die Operatoren von jeglicher feldbusspezifischer Steuerung. Der Stub ermöglicht die Definition von Befehlsfolgen zur Laufzeit, z. B. „setze Aktor MOTOR auf ein“ gefolgt von „lese Wert vom Sensor METALLDETEKTOR“. Jede einzelne Abfolge kann ebenfalls als Mikrocode bezeichnet werden, da sie die kleinsten logischen Operation darstellen, die der Stub aus der Sicht der Operatoren ausführen kann. Ein Operator muss daher alle von ihm benötigten Befehlsfolgen erstellen und dem Stub mitteilen sowie die ausgetauschten Binärwerte interpretieren können. Jede Befehlsfolge wird als Ganzes in Echtzeit ausgeführt und Nebenläufigkeitsprobleme mit anderen gestarteten Befehlsfolgen (z. B. von anderen Operatoren) werden vermieden. Nachdem eine Befehlsfolge ausgeführt wurde, liefert der Stub Rückgabewerte für einzelne Befehle, z. B. das Gewicht eines Bauteiles, und Informationen über Zeit- und Energieverbrauch, die zu Entscheidungsfindungen genutzt werden können. Beispiel: Transport eines Bauteilträgers Als Beispiel dient ein Agent, der einen Bauteilträger von einem Hochregallager zu einem Roboter bewegen will, der sich an einem anderen Standort befindet. Das Hochregallager, das Verteilsystem und Arbeitsplätze sind über Fließbänder miteinander verbunden. Jede Station wird von einem Agenten verwaltet. Den Agenten sind nur Übergabepunkte bekannt, welche zu anderen Transportsystemen mit Agenten führen, und Punkte, an denen Arbeit verrichtet werden kann. Der jeweils zu einem Agenten gehörende Pfadoperator ist für die Pfadsuche und das Routing zuständig und kennt Befehls-

Leicht konfigurierbarer HAL

103

folgen, um einen Bauteilträger von einem Punkt zu einem anderen zu bewegen. Dem Pfadoperator können zusätzliche Punkte bekannt sein, um beispielsweise Bauteilträger über alternative Routen zu bewegen, falls eine direkte Route blockiert ist. Der Operator kommuniziert dann mit einem Stub, um die Hardware zu steuern. Dieser wird die Befehle mit Hilfe der benötigten Protokolle auf den Feldbussen umsetzen und entsprechende Bits setzen oder lesen.

3 Implementation Alle zur Steuerung nötigen E/A-Operationen werden vom Stub abstrahiert. Komplexere Feldbusgeräte wie RFID-Lesegeräte kommunizieren über eigene High-Level-Protokolle, um Werte zu lesen oder zu setzen. Eine Feldbuskomponente, ein Protokoll und eine geräteinterne Adresse werden abstrahiert Symbol genannt. Dieses Symbol wird in der Stubkonfiguration mit einem Namen versehen, auf das der Nutzer transparent zugreifen kann. Symbole erlauben verschiedene Zugriffsmodi (lesen, schreiben, lesen und schreiben), die in der Konfiguration mit SET und GET angegeben werden müssen. Eine einfache Konfigurationsdatei des Stubs sieht wie folgt aus:

 



                        

                     

     



          !  "##  $ 

##

 %&'  

 (&'        

104

U. Schmidtmann et al.

Neben dem Lesen und Schreiben von Prozesswerten wird auch das Warten auf einen bestimmten Wert vom Stub unterstützt. Durch die Kombination dieser drei E/AOperationen sind die Abläufe in der Digitalen Fabrik einfach umzusetzen. Eine Sequenz dieser E/A-Operation wird als Task zusammengefasst und hat einen Namen. Der Pfadoperator zum Beispiel generiert sie für die einzelnen Segmente anhand seiner Konfigurationsdatei. Dort wird jede Task auch mit einer ungefähren Ablaufdauer konfiguriert, die zur Ermittlung des kürzesten Weges benutzt wird und während des laufenden Betriebes durch Statistiken an den Realwert angenähert werden kann. Ein Kommando ist eine E/A-Operation auf ein Symbol und wird mit folgenden Parametern benutzt: Verzögerung, Aktion (GET, SET oder WAIT), Symbolname, Wert und Timeout. Eine Beispielkonfiguration mit einer Task, die einen Motor betreibt bis ein Sensor seinen Wert auf 1 ändert, ist in Abb. 2 (links) dargestellt. Es gilt zu beachten, dass das zweite Kommando einen Timeout konfiguriert, der verhindert, dass der Motor ununterbrochen läuft. Falls der Sensor nicht spätestens nach 10 Sekunden den Wert 1 hat, stellt der Stub den Motor ab und meldet einen Fehler. Es ist auch wichtig, den Motor rechtzeitig auszuschalten, um zu verhindern, dass zu weit gefahren wird. Daher muss die Beispieltask unter Echtzeitbedingungen ausgeführt werden. Der Stub garantiert dies, weil die kritische Programmlogik in einem RTAI-Linux-Kernelmodul ausgeführt wird. Bevor eine Task ausgeführt werden kann, ist es notwendig, dass sämtliche Kommandos vorher definiert werden. Dies kann dynamisch während der Laufzeit gemacht werden. 3.1 Zugriffsschutz In vielen Anwendungen müssen Operatoren exklusiven Zugriff auf ihre Hardware haben, damit kein anderer Operator kritische Symbole beeinflusst. Zu diesem Zweck müssen Symbole vor Verwendung reserviert werden. Die Reservierung kann in zwei verschiedenen Stufen erfolgen: exklusiv oder shared. Exklusiver Zugriff garantiert, dass kein anderer Operator das Symbol lesen oder schreiben darf, wohingegen Shared-Zugriff anderen Operatoren ebenfalls Zugriffe erlaubt. Falls ein Operator bereits exklusiven Zugriff bekommen hat, erhält solange kein anderer Zugriff, bis der erste seine Rechte auf shared wechselt oder komplett aufgibt. 3.2 Stubprotokoll Operatoren verbinden sich zu einem Stub, reservieren die Symbole, auf die sie zugreifen wollen und definieren anschließend ihre Tasks. Wenn weder Konflikte noch unbekannte Symbole auftreten, kann der Operator diese Tasks starten. Der Stub gibt für jedes ausgeführte Kommando die tatsächliche Ablaufdauer für jedes Kommando zurück. Diese Angaben werden bei entsprechenden Hardwarevoraussetzungen mit Energieverbrauchswerten ergänzt, so dass eine genaue Kostenverfolgung und eine Prozessoptimierung auf höherer Ebene durchgeführt werden kann. Der Stub bedient einen Operator in einer TCP-Session und gibt alle Ressourcen frei, sobald sie beendet wird. Der Operator kann die Ressourcen auch explizit freigeben. Für jede Anfragezeile antwortet der Stub mit der gleichen Zeile mit dem Unterschied, dass er ok oder im Fehlerfall error voranstellt.

Leicht konfigurierbarer HAL

105

Abb. 2: links: Taskdefinition im Pfadoperator, rechts: Dialog zwischen Operator und Stub.

Eine Kommunikation entsprechend des ursprünglichen Beispiels könnte wie in Abb. 2 (rechts) ablaufen. 3.3 Parallele Ausführung Es gibt keine Möglichkeit, den Kontrollfluss innerhalb einer Task anhand von Sensorwerten zu beeinflussen. Daher müssen die Operatoren Strukturen wie Verzweigungen, Schleifen und ähnliches durch Kombination entsprechender Tasks realisieren, wodurch die Echtzeitfähigkeit für taskübergreifende Problemstellungen verlorengeht. Einerseits scheint dies eine starke Einschränkung zu sein, andererseits vereinfacht es das Programmdesign des Stubs, der für die Ausführung unter Echtzeitbedingungen verantwortlich ist. Es ist von vornherein bekannt, welches Symbol für welche Art von Kommando genutzt werden wird. Darauf aufbauend können alle eingehenden Taskaufrufe in eine Warteschlange eingereiht werden. Sobald die Einhaltung der Echtzeitbedingungen in Bezug auf konkurrierende Operatorzugriffe für eine Task garantiert werden kann,

106

U. Schmidtmann et al.

wird diese vom Stub zur sofortigen Ausführung an die RTAI-Komponente des Stubs gesendet. Die verzögerte Ausführung ist unkritisch, da die Kommunikation zwischen Operator und Stub ohnehin nicht echtzeitfähig ist. Über die Warteschlange wird sichergestellt, dass Hardwarekomponenten, die lediglich für sequenziellen Zugriff ausgelegt sind, nicht durch parallele Zugriffe gestört werden. Dies ist besonders bei den angesprochenen drivecom- und ident-Geräten der Fall. Die Kommunikation mit einer Feldbuskomponente über ein High-Level-Protokoll verbraucht relativ viel Zeit, in der auf eine Antwort gewartet wird. Besonders beim Zugriff auf mehrere Symbole innerhalb eines Gerätes wird viel Bandbreite und Zeit verschwendet. Die RTAI-Komponente füllt diese Leerlaufzeiten mit anstehenden E/AOperationen anderer Tasks. Diese Parallelisierung verbessert den gesamten Ablauf und die mittlere Antwortzeit deutlich. Mit dem Stub als hardwareabstrahierendes System, das Mikrocodes parallel ausführen kann und dabei Echtzeitbedingungen einhält, können Operatoren Hardware steuern, ohne sich dabei mit anderen Operatoren synchronisieren zu müssen.

4 Fazit und Ausblick Damit ein effizienter Arbeits- und Materialfluss erzielt werden kann, muss eine übergreifende Optimierung von einem kontrollierenden Agentensystem durchgeführt werden, bei der Energieeffizienz, Produktqualität und Durchsatz die Schlüsselelemente sind. Daher muss jeder Agent, der einen Arbeitsplatz, ein Lager, ein Transportsystem etc. kontrolliert, über vollen Zugriff auf alle Parameter und jeden einzelnen Schritt der möglichen Aktionen auf der unterliegenden Hardware verfügen und die Rückgabewerte zu Zeit- und Energieverbrauch analysieren. Dennoch ist für Agenten kein tiefgreifendes Wissen zur Nutzung der vollen Funktionalität der Hardware nötig. Der HAL, der in diesem Beitrag beschrieben wird, ist eine neue Vorgehensweise, um die Feldkontrolle auf diese Weise zu organisieren. Der Stub ist die niedrigste Schicht mit vollständigem Wissen über alle Aktoren und Sensoren der Automatisierungseinheiten. Aktoren und Sensoren werden einheitlich definiert und in XML-Dateien als Symbole beschrieben, die dann in einfachen Befehlsfolgen genutzt werden. Das bedeutet, dass neue Funktionalitäten hinzugefügt werden können, indem XML-Dateien angepasst werden. Des Weiteren können Änderungen am Fabrikentwurf oder eine Migration auf eine komplett neue Hardware durchgeführt werden, indem lediglich neue XML-Dateien angelegt werden; die Software muss nicht modifiziert werden. Hierdurch war es möglich, XML-Dateien für ein völlig neues Automatisierungsmodell mit 312 digitalen und analogen Ein- und Ausgängen innerhalb von nur zwei Stunden zu schreiben, inklusive dem Erstellen von Tasks. Der Stub synchronisiert und parallelisiert die Befehlsfolgen, die in der darüberliegenden Unterschicht von den Operatoren erstellt wurden, und verwaltet alle Aktivitäten, deren Durchführung Echtzeitverarbeitung voraussetzen. Die Aufteilung des HAL in Stubs und Operatoren erlaubt eine bessere Verteilung der Software über Systemgrenzen hinweg, falls die verfügbaren Hardwareressourcen des Zielsystems nicht ausreichen. Diese Funktionalität hilft insbesondere dabei, Automatisierungssysteme im

Leicht konfigurierbarer HAL

107

Hinblick auf Energieeffizienz und Integration bereits vorhandener Hardware mit unterschiedlichen Eigenschaften zu modellieren. Da eine Erstellung von großen XML-Dateien zur Konfiguration als sehr fehleranfällig angesehen werden kann, werden Programme entwickelt, die den Benutzer bei der Erstellung eines vollständigen agentenbasierten Produktionsprozesses assistieren.

5 Danksagung Die Autoren möchten sich bei dem Bundesministerium für Bildung und Forschung (BMBF) für das Sponsoring und die Unterstützung des LK3 S-Projektes bedanken. Ferner gilt der Dank der Autoren der Volkswagen-Stiftung für die Förderungen der Forschung im Bereich Cluster-Computing, von der Ideen mit in das Projekt eingehen. LK3 S ist ein Gemeinschaftsprojekt der Fachhochschulen Emden/Leer und Osnabrück, das zusammen mit den Industriepartnern Phoenix Contact, Schneider Electric Automation und SENGATEC durchgeführt wird. Die Autoren möchten daher allen Partnern für ihre Unterstützung und ihre wertvollen Anregungen danken, welche helfen, den Ansatz stetig zu verbessern.

Literaturverzeichnis 1. EU-Kommission: MANUFACTURE — a vision for 2020 Assuring the future of manufacturing in Europe, Office for Official Publications of the European Communities, ISBN 92894-8322-9, Luxemburg 2004 2. EU-Kommission: Towards an IST Strategy for Manufacturing, EU-Kommission, Draft Internal Report, 2004 3. HMS: Holonic Manufacturing Systems Project Consortium,     

, 2003 4. A. Cannata, M. Gerosa, und M. Taisch: A Technology Roadmap on SOA for smart embedded devices: Towards intelligent systems in manufacturing, IEEE International Conference on Industrial Engineering and Engineering Management (IEEM 2008), S.762-767, Dezember 2008 5. D. Cachapa, A. Colombo, M. Feike und A. Bepperling: An approach for integrating real and virtual production automation devices applying the service-oriented architecture paradigm, Conference on Emerging Technologies and Factory Automation (ETFA2007), S. 309-314, September 2007 6. L. Ferrarini u.a.: Control Architecture for Reconfigurable Manufacturing Systems: the PABADIS’PROMISE approach, IEEE Conference on Emerging Technologies and Factory Automation (ETFA2006) S. 545-552, September 2006 7. V. Herrera, u.a.: Integration of Multi-Agent Systems and Service-Oriented Architecture for industrial automation, 6. International Conference on Industrial Informatics (INDIN 2008), S. 768-773, Juli 2008 8. A. Lüder, A. u.a.: Distributed Automation: PABADIS versus HMS, IEEE Trans. Industrial Informatics, Band 1, Nr.1, S. 31-37, Februar 2005 9. J.G. Bollinger u.a.: VISIONARY MANUFACTURING CHALLENGES FOR 2020, Committee on visionary manufacturing challenges National Academy Press, Washington DC 1998

108

U. Schmidtmann et al.

10. J Peschke, A. Lüder H. Kuhnle: The PABADIS’PROMISE architecture - a new approach for flexible manufacturing systems, IEEE Conference on Emerging Technologies and Factory Automation (ETFA2006) S. 491-496, September 2006 11. A. Cannata, M. Gerosa und M. Taisch: SOCRADES: A framework for developing intelligent systems in manufacturing, IEEE International Conference on Industrial Engineering and Engineering Management (IEEM 2008), S.1904-1908, Dezember 2008

Universeller hybrider Systembeobachter für Echtzeitsysteme Björn Pietsch Institut für Regelungstechnik, Leibniz Universität Hannover Appelstr. 11, 30167 Hannover       

Zusammenfassung. Bei der Entwicklung von Echtzeitbetriebssystemen und Echtzeitanwendungen ist die Verfolgung der logischen und zeitlichen Abläufe von hoher Bedeutung für Fehlersuche und Verifikation. Die Abläufe sind mit minimaler Beeinflussung des Zielsystems zu erfassen, um realistische Werte zu erhalten, wofür sich hybride Systemmonitore als geeignet erwiesen haben. Der Beitrag stellt den flexiblen Systembeobachter OSOBS vor, der neben der Aufzeichnung der Abläufe in der Software auch die Erfassung von Ereignissen im angesteuerten System ermöglicht. Er vereinfacht dadurch die Analyse der Daten und ermöglicht weitergehende Untersuchungen als bisherige Ansätze. Der Beitrag stellt sowohl die entwickelte Hardware als auch die Instrumentierung und die Analysesoftware vor, präsentiert mit dem System gewonnene Messdaten und diskutiert die Effizienz des Systems.

1 Grundlagen und vorhandene Arbeiten Eingebettete Echtzeitsysteme verbreiten sich zunehmend und übernehmen dabei ständig komplexere Aufgaben. Die Verfügbarkeit leistungsfähiger und zugleich stromsparender und preisgünstiger Mikrocontroller und Prozessoren erschließt heute auch Gebiete wie Bildverarbeitung und aufwändige Navigation für kostensensible Anwendungen. Zudem werden zunehmend verschiedene Funktionen, die bislang in getrennten Systemen ausgeführt wurden, in einem gemeinsamen Rechner untergebracht. Dies reduziert einerseits die Anzahl der erforderlichen Hardwarekomponenten, andererseits nehmen die Wechselwirkungen zwischen den parallelen Prozessen zu. Da die Prozesse von unterschiedlicher Kritikalität sein können, müssen die Wechselwirkungen genau untersucht werden. Ein Beispiel sind autonome Serviceroboter, die sowohl sicherheitskritische Funktionen enthalten als auch komplexe Aufgaben wie Objektsuche und Navigation ausführen. Für die Entwicklung und Validierung derartiger Systeme – sowohl auf der Betriebssystem- als auch auf der Anwendungsebene – muss man die logischen und zeitlichen Abläufe in der Software und der angeschlossenen Hardware verfolgen können. Dadurch lassen sich nicht nur unmittelbare Fehler erkennen, sondern auch ineffiziente Abläufe aufspüren oder Parametrierungen für komplexe Middleware wie Ressourcenmanagementsysteme optimieren. Herkömmliche Debugger erfüllen die Anforderungen nur unzureichend, weil sie zeitliche Abläufe weitgehend unberücksichtigt lassen; ihr primäres Einsatzgebiet ist

110

B. Pietsch

die Fehlersuche in logischen Abläufen einzelner Anwendungen. Die Verfolgung von Aktivitäten über Anwendungsgrenzen hinaus sowie innerhalb von Betriebssystemen erfordert entsprechende Unterstützung und ist aufwändig. Zudem müssen Debugger die untersuchten Programme für genauere Untersuchungen anhalten, was in Echtzeitsystemen in aller Regel inakzeptabel ist. Die wesentlichen Ziele für die Beobachtung eingebetteter Echtzeitsysteme sind eine minimale Beeinflussung der Systemabläufe durch die Beobachtung und die Beschränkung auf relevante Daten (z. B. Interrupts, Prozessumschaltung, Semaphoroperationen), um die Analyse zu vereinfachen. Dieser Beitrag schließt damit an frühere Forschungsarbeiten des Institutes zu nichtinvasiven Messverfahren für die Verteilung von Latenzzeiten in Echtzeitbetriebssystemen an [1]. Systeme zur Aktivitätserfassung in Echtzeitrechnern lassen sich in drei Klassen einteilen: 1. Passive Systeme auf Hardwarebasis benötigen keine Änderungen an der Software, sondern erfassen alle Aktionen passiv durch Beobachtung der Bussysteme und Netzwerkverbindungen. 2. Softwarebasierte Systeme laufen vollständig im zu beobachtenden System ab und verwenden dessen Ressourcen. Zusätzliche Hardware ist unnötig, aber es sind Änderungen am Betriebssystem und den Anwendungen erforderlich. 3. Hybridsysteme vereinen die beiden anderen Ansätze, indem sie ebenfalls Änderungen an der vorhandenen Software notwendig machen, aber zugleich externe Hardware für die Aufzeichnung und Analyse einsetzen. Man kann demnach mit steigendem Hardwareaufwand die Beeinflussung des zu beobachtenden Systems reduzieren. Für eine exakte Analyse wären rein passive Systeme ideal. Sie lassen sich in modernen Rechnern allerdings kaum ohne spezielle Hardwareunterstützung realisieren, da man Informationen über die von der CPU ausgeführten Befehle und die dabei verwendeten Daten benötigt. Während Mikrocontroller oft als System on Chip (SoC) eingesetzt werden und alle Speicher in einem Chip vereinen, besitzen leistungsfähigere Prozessoren Caches, die einen Großteil der Speicherzugriffe (mehr als 99, 5 % [2]) nach außen unsichtbar machen. In beiden Fällen ergeben sich erhebliche Leistungseinbußen, wenn man die Systeme zur Darstellung ihrer Zugriffe an beobachtbaren Bussen zwingt. Als Lösung bieten sich spezielle Module innerhalb der Prozessoren an, die über unabhängige Kanäle Daten über die Abläufe ausgeben. Beispiele sind der Nexus5001Standard [3] oder die Trace-Ports in manchen ARM-Prozessoren. Derartige Lösungen sind jedoch prozessorspezifisch und daher schlecht portierbar und lassen auch keine Beobachtung peripherer Systeme wie Feldbusse zu. Zudem sind die Daten unspezifisch in Bezug auf Betriebssysteme, weil vorrangig Informationen über Sprünge ausgegeben werden. Aus diesen lassen sich zwar die relevanten Daten rekonstruieren, aber der Rohdatenstrom kann im Bereich einiger GBit/s liegen. Rein softwarebasierte Systeme sind leicht portierbar und von Hardwarestrukturen unabhängig. Sie üben aber einen teils erheblichen Einfluss auf das zu beobachtende System aus, weil sie dessen Ressourcen verwenden, und verfälschen damit die Ergebnisse, wobei das Ausmaß jedoch sehr unterschiedlich sein kann. Insbesondere Linux

Universeller hybrider Systembeobachter für Echtzeitsysteme

111

besitzt inzwischen eine erhebliche Anzahl an Trace-Modulen. So kann der Funktionentracer ftrace Funktionsaufrufe verfolgen und unter anderem die maximal aufgetretene Stackgröße ermitteln. Eine Rekonstruktion aller aufgetretenen Größen und Abfolgen ist jedoch nicht möglich, weil die notwendige Datenmenge zu groß würde. Das aufwändigere Linux Trace Tool next generation (LTTng [4]) hingegen zeichnet sehr genaue Traces auf und ermöglicht tiefgehende Analysen mit dem Visualisierungstool LTTV. Zur Aufzeichnung werden aber große Speichermengen im Dateisystem benötigt. Die höhere Genauigkeit geht also mit einem höheren Ressourcenverbrauch und damit Einfluss auf die Anwendungen einher. Problematisch ist dies insbesondere beim Einsatz in Systemen, bei denen die Aufzeichnungsdauer durch die Dauer externer Vorgänge wie der Bewegung eines Roboters vorgegeben ist. Diese dauern um Größenordnungen länger als interne Abläufe, weshalb sich sehr große Ereignisanzahlen ergeben. Hybride Beobachter nutzen Prinzipien aus beiden Ansätzen, um die spezifischen Nachteile zu reduzieren. Dabei wird die Software so modifiziert, dass sie relevante Aktionen nach außen meldet. Zur Aufnahme der Meldungen wird Hardware eingesetzt, die die Aufzeichnung und Analyse übernimmt. Durch dieses Verfahren werden einerseits genau die relevanten Daten ausgegeben, weshalb die Aufzeichnung effizient bleibt, und andererseits die in die Software einzubringenden Änderungen einfach gehalten sowie die Systemressourcen geschont. Hybride Systeme profitieren daher von den Vorteilen der beiden reinen Verfahren. Das Konzept ist bereits vielfach erprobt. In [5] wurde ein Hybridbeobachter zur Unterstützung des Schedulers im Hauptsystem eingesetzt. [6] zeigt eine neuere Realisierung, die sich auf digitale IO-Ports des Controllers stützt und die Daten in einem eigenen Speicher von 30 MB ablegt. In gleicher Weise arbeitet das kommerzielle Produkt RTBx [7], das jedoch eine sehr leistungsfähige Hardware besitzt. Allerdings zielt RTBx auf die Beobachtung einzelner Anwendungen mit automatischer Instrumentierung; Betriebssystembeobachtung und Multitasking werden nicht direkt unterstützt. Ein hinreichend flexibles Hybridsystem, das sich auf Betriebssysteme anwenden lässt und auch mit leistungsfähigen Prozessoren ohne digitale IO-Ports verwendbar ist, existiert bislang nicht. Daher wurde im Rahmen eines Forschungsprojektes zum Ressourcenmanagement für Serviceroboter der Beobachter OSOBS (Operating System Observer) entwickelt, der die Nachteile bestehender Systeme umgeht.

2 Hardware Ziel des OSOBS-Projektes war es, einen flexiblen und von der Hardware des zu untersuchenden Systems möglichst unabhängigen Beobachter zu entwickeln, der sowohl interne Aktionen der Software als auch Aktivitäten in der Peripherie aufzeichnen kann. Die Hardware verfügt auch über Feldbusschnittstellen, da bei ausschließlicher Verwendung von Standardhardware für die Feldbusbeobachtung wegen fehlender Zeitinformationen Probleme mit der Datenintegration auftreten. OSOBS ist ein dreigeteiltes System aus der als OSOBS-Master bezeichneten Zentraleinheit, einem separaten Datenaufnehmer und dem Host-PC (siehe Abb. 1). Der Master enthält die Teilsysteme zur Überwachung der Peripherieeinheiten, einen Pufferspeicher und ein USB-Modul zur Verbindung des Masters mit dem Host-PC. Der

112

B. Pietsch

zum Roboter

CAN-Busse

CANController USB-Modul

Leitrechner PCI (RTOSUH)

Aufnehmer cPCI

USB

Host-PC

FPGA HSSI (High Speed Serial Interface)

RAM

Interruptleitungen OSOBS-Master

Abb. 1: OSOBS-Struktur für die Zielanwendung an einem Serviceroboter

Datenaufnehmer ist eine an die Zielhardware angepasste Einheit, die die Daten aus der instrumentierten Software aufnimmt. Der Aufnehmer ist über schnelle serielle Kanäle mit dem Master verbunden und daher leicht auszutauschen, um verschiedene Systeme beobachten zu können. Das Gesamtsystem könnte prinzipiell noch modularer gestaltet werden, insbesondere bei der Anbindung zusätzlicher Peripherieüberwachungen. Da es sich aber um einen Forschungsprototypen handelt, wurden nicht alle Möglichkeiten ausgereizt. 2.1 Master Der OSOBS-Master sammelt als Zentraleinheit mit einem FPGA die Daten aller Ereignisquellen und bringt sie auf ein einheitliches Format, bevor sie an den Host-PC weitergegeben werden. Ein Ereignis besteht dabei aus 16 Byte, die sich wie folgend aufteilen: – – – –

4 Byte Zeitstempel in der Auflösung der Quelle 4 Byte OID (Originator ID, identifiziert den verursachenden Prozess) 4 Byte EID (Event ID, identifiziert das Ereignis, z. B. Semaphoraufruf) 4 Byte Statusdaten

Der Master ist die Schnittstelle zwischen der Echtzeitebene und dem Host-PC. Er besitzt eine schnelle USB-Verbindung, über die während einer Messung die empfangenen Daten ständig zum PC gesendet werden. Die Aufzeichnungskapazität ist dadurch praktisch unbegrenzt; der Master enthält nur einen Pufferspeicher von 4 MiB, um vom PC verursachte Pausen in der Übertragung abzufangen. Zur Anbindung der Datenaufnehmer stehen drei synchrone serielle Kanäle mit je 50 MBit/s zur Verfügung, wobei technisch noch Potential für eine Vervierfachung der Datenrate besteht. Ein Rückkanal dient der Protokollabwicklung sowie der Steuerung des Aufnehmers. CPU-Schnittstelle Im Master wurde ein direkter Anschluss für den CPU-Bus von Mikrocontrollern vorgesehen. Dadurch können Controller mit offen zugänglichem Datenbus ohne Verwendung eines Aufnehmers angeschlossen werden. Es handelt sich um

Universeller hybrider Systembeobachter für Echtzeitsysteme

113

einen Anschluss mit 64 Eingängen auf 3,3 V-Niveau, der an verschiedene Protokolle angepasst werden kann. Er ist für eine rein passive Busbeobachtung vorgesehen und damit als Snooper auf dem Bus zum RAM verwendbar. Die Zeitstempel beim Zugriff werden im FPGA erzeugt, da der zeitliche Zusammenhang zwischen Befehlsausführung und Buszugriff bei Mikrocontrollern hinreichend eng ist; der Controller spart auf diese Weise die Zeit zur Erzeugung und Übertragung des Stempels. Der Anschluss wurde bislang exemplarisch an einem MPC555-Controller mit 40 MHz getestet. Peripherieschnittstellen Der Master verfügt über 6 frei programmierbare IO-Pins, die im FPGA mit programmierbaren Impulsgeneratoren oder Flankendetektoren verbunden werden können. Dadurch kann man gezielt Interrupts im System auslösen oder Latenzzeiten bei der Reaktion auf externe Ereignisse erfassen. Zudem lassen sich diese Funktionen nutzen, um eine Beziehung zwischen den Zeitstempeln des FPGAs und solchen aus einer CPU herzustellen. Da in den Roboterprojekten des Institutes vorrangig der CAN-Bus zur Vernetzung eingesetzt wird, wurde der Master mit vier CAN-Kanälen ausgerüstet, wobei das CANProtokoll von externen Controllerbausteinen abgewickelt wird, die mit dem FPGA verbunden sind. Sie agieren am Bus als rein passive Empfänger, der Empfangszeitpunkt sowie die ID und Länge empfangener CAN-Botschaften werden vom FPGA aufgezeichnet. Die Dateninhalte werden bislang nicht aufgezeichnet, gleichwohl eine Nachrüstung der Funktion möglich ist. Es ist jedoch auch relativ einfach, mit Standardhardware die Dateninhalte aufzuzeichnen und sie über die ungefähre zeitliche Korrelation nachträglich zuzuordnen. 2.2 Datenaufnehmer

Protokollmaschine

Puffer

Paketlogik und HSSI

zum Master

PCI-WishboneBridge

HSSI-Anschluss

cPCI-Anschluss

Die Aufgabe des Datenaufnehmers besteht darin, für das zu beobachtende System einen schnellen Datenpfad bereitzustellen, über den die Daten der Ereignisse aus der Software ausgegeben werden können. Dabei ist es vorteilhaft, vorhandene Verbindungen wie PCI, VME oder vergleichbare Bussysteme zu nutzen.

Statuslogik FPGA XC3S250E

Abb. 2: Realisierung eines Datenaufnehmers: Struktur des OSOBS-cPCI-Targets

114

B. Pietsch

← 4 Byte → 0x8201 FFFC 0x8201 7FFC 0x8201 0000 0x8200 8000

Zeitzelle

mit dem Offset eines Speicherbefehls erreichbarer Bereich

0x8200 0000 Abb. 3: Aufteilung des Speicherfensters für das OSOBS-cPCI-Target. Die Adresse der Zeitzelle kann als 16 Bit-Konstante mit einem Befehl geladen werden; der übrige Speicherbereich des Targets wird dann mit Offsets relativ dazu adressiert.

Im Rahmen des Projektes wurde für das hauptsächlich verwendete Rechnersystem ein Datenaufnehmer in Form einer CompactPCI-Karte aufgebaut (siehe Abb. 2). Das Design erlaubt einen einfachen Transfer auf andere PCI-basierte Industriestandards wie PC-Steckkarten, PMC oder PC-104, da nur das Layout der Leiterplatte anzupassen ist; der elektrische und logische Aufbau bleibt erhalten. Bezogen auf den PCI-Bus handelt es sich beim Datenaufnehmer um ein PCI-Target, in das nur geschrieben wird. Der logische Aufbau ist dadurch einfach in einem FPGA zu realisieren, wofür eine als Open Source verfügbare PCI-Wishbone-Bridge [8] vereinfacht wurde. Sie übersetzt die PCI-Zugriffe in Zugriffe auf den FPGA-internen Wishbone-Bus, der einem CPU-Bus ähnlich ist. Eine Zustandsmaschine überwacht die Zugriffe auf den Bus und nimmt die übertragenen Daten auf. Dabei werden den einzelnen Zellen des PCI-Speicherfensters Funktionen zugewiesen (siehe Abb. 3). So wird der Zeitstempel, der wegen der losen zeitlichen Kopplung zwischen Befehlsausführung und Buszugriff in der CPU gebildet werden muss, immer zuerst und in die Mitte des Fensters geschrieben. Der zweite Zugriff schreibt dann die OID in eine andere Zelle innerhalb eines 64 KiB-Bereiches, wobei der Adressoffset zugleich die EID darstellt. Die Zustandsmaschine erkennt Verletzungen der Zugriffsreihenfolge, wie sie auftreten können, wenn ein Interrupt die Befehlsfolge eines Instrumentierungspunktes unterbricht. Die fehlerhaften Daten werden markiert und dann übertragen, um bei einer späteren Analyse die korrekte Reihenfolge rekonstruieren zu können (siehe Abschnitt 3.2). Die erfassten Ereignisse werden lokal im FPGA gepuffert, in Pakete gebündelt und mit einer Prüfsumme gesichert an den Master übertragen, wobei auch eine Korrektur von Übertragungsfehlern durch eine Paketwiederholung möglich ist.

3 Software Die für eine Beobachtung erforderliche Software besteht aus zwei Teilen: Einerseits die Instrumentierung des Betriebssystems und der Anwendungen, die dafür sorgt, dass an den relevanten Stellen Informationen über die Ereignisse an den Beobachter geschickt

Universeller hybrider Systembeobachter für Echtzeitsysteme

115

werden, andererseits die Software des Host-PCs zur Steuerung des Beobachters und zur Analyse der erhaltenen Daten. Der Instrumentierungscode ist dabei sicherheitskritisch, weil er in die Echtzeitsoftware eingreift und daher unmittelbar deren Verhalten beeinflusst. Die Analysesoftware hingegen ist prinzipiell unkritisch, wobei sie angesichts der großen Datenmengen dennoch effizient sein muss, um ein sinnvolles Arbeiten zu ermöglichen. 3.1 Instrumentierung Die Instrumentierungspunkte müssen die EID und OID des aktuellen Ereignisses übertragen sowie im Falle separater Datenaufnehmer mit loser zeitlicher Kopplung an die Befehle auch einen Zeitstempel. Um die Rückwirkung der Instrumentierung klein zu halten, dürfen die Punkte nur kurze Befehlsfolgen enthalten, wobei die Relation zum jeweiligen System zu wahren ist. Bislang wurden Instrumentierungen für die Echtzeitbetriebssysteme RTOS-UH und Linux/Xenomai auf PowerPC-Prozessoren umgesetzt. Entsprechend der jeweiligen Implementierung wurden die Instrumentierungspunkte in Assembler bzw. C eingebracht. In RTOS-UH sind fünf Maschinenbefehle ausreichend, da hier eine einfache Speicherstruktur vorliegt und das Speichermodell des Aufnehmers vollständig genutzt werden kann. Der virtuelle Adressraum unter Linux erzwingt die Verwendung eines Treibers für den Datenaufnehmer, weshalb die Instrumentierungspunkte einen zusätzlichen Test und damit 13 Maschinenbefehle einschließlich eines bedingten Sprunges benötigen. Eine Effizienzsteigerung ist hier möglich, indem man zur Aktivierung der Instrumentierung zur Laufzeit Befehle austauscht, wie es die Software-Tracer in Linux bereits tun. Instrumentierungspunkte können von Interrupts unterbrochen werden, da sie aus mehreren Speicherzugriffen bestehen. Sofern die Instrumentierung nur im Betriebssystem erfolgt, ist dies relativ unproblematisch, weil viele Abläufe dort dem Prinzip last in, first out folgen. Sofern man keine Instrumentierungspunkte in abbrechbaren oder prozessähnlichen Systemfunktionen installiert, gilt dieses Prinzip auch für die Punkte und damit für die Zugriffe auf den Datenaufnehmer; die ursprüngliche Reihenfolge ist rekonstruierbar. Problematischer ist hingegen die Instrumentierung von Anwendungsprozessen, weil diese grundsätzlich nicht dem LIFO-Prinzip unterliegen, sondern vom Prozessumschalter nach einer Unterbrechung in beliebiger Reihenfolge fortgesetzt werden können. 3.2 Steuerung und Analyse Zur Steuerung des Beobachters und zur Analyse der Daten wurde eine Windows-Anwendung für den Host-PC erstellt. Sie übernimmt die Parametrierung des Beobachters und empfängt die Daten über die USB-Verbindung. Die in gesicherten Paketen empfangenen Daten werden im PC wieder in den ursprünglichen Datenstrom umgewandelt und binär auf die Festplatte geschrieben. Der begrenzende Faktor bei der Übertragung ist dabei die USB-Verbindung, die eine Übertragung von maximal 20 MB/s (entsprechend 1,25 Mio. Ereignissen/s) zulässt.

116

B. Pietsch

Vorverarbeitung Die erfassten Daten müssen vor der Analyse einer Vorverarbeitung unterzogen werden. Dabei werden die binären Dateien in XML-Dateien umgesetzt und zugleich für schnellere Suchoperationen indiziert. XML benötigt zwar mehr Speicher als Binärdaten, aber es ist flexibler bei der Einführung neuer Datenfelder und unterstützt Felder variabler Länge (z. B. Kommentartexte oder Prozessnamen) besser. Zudem sind fertige Parser verfügbar, was den Aufwand zur Erstellung der Software reduziert. Nach der Umwandlung werden Konsistenzprüfungen durchgeführt (z. B. Monotonie der Zeitstempel, Gültigkeit der EID- und OID-Einträge), um gegebenenfalls Übertragungsfehler zu erkennen. Bei der Prüfung werden auch als fehlerhaft gemeldete Ereignisse darauf überprüft, ob sie durch Unterbrechungen eines Instrumentierungspunktes entstanden sind. Wenn das der Fall ist, wird die Ereignisfolge rekonstruiert und der Datenstrom entsprechend umgeordnet. Eine weitere Aufgabe der Vorverarbeitung ist die Vereinheitlichung der Zeitmessungen. Da das FPGA und die mit einem Datenaufnehmer angekoppelte CPU jeweils eigene Zeitbasen besitzen, existieren zwischen ihnen Drift und Auflösungsunterschiede. Während die verschiedenen Taktfrequenzen einfach durch Umrechnung auf einen gemeinsamen Maßstab von Nanosekunden gebracht werden, erfordert die Korrektur der Drift höheren Aufwand. Sie ist nur dann möglich, wenn Ereignisse in beiden Zeitbasen erfasst werden. Dafür lassen sich periodisch vom FPGA erzeugte Interrupts nutzen, die über einen IO-Pin an den Rechner ausgegeben und dort registriert werden. Wenn der Interrupthandler so instrumentiert ist, dass die Latenzzeit zwischen dem elektrischen Signal und dem Instrumentierungspunkt nahezu konstant ist, ist eine Driftkorrektur möglich. Analyse Die Datenanalyse ermittelt aus dem Datenstrom der Ereignisse die eigentlichen Abläufe sowie statistische Werte. Dabei sind die letztlichen Analysemöglichkeiten abhängig von der Instrumentierungsdichte. So kann beispielsweise die Zeit für einen Kontextwechsel nur separat erfasst werden, wenn Beginn und Ende des Prozessumschalters instrumentiert sind; ist nur ein Punkt vorhanden, kann nur der Wechsel an sich zeitlich festgelegt werden. Statistische Werte über Ereignisse (Anzahl registrierter Ereignisse absolut und je Zeiteinheit, insgesamt und pro Prozess) lassen sich unmittelbar aus dem Datenstrom gewinnen. Für Aussagen über Zeitverteilungen (z. B. CPU-Last, effektive Laufzeit eines Prozesses in Relation zur Zeit zwischen Aktivierung und Ende) sowie zur grafischen Darstellung der Prozesszustände benötigt man hingegen zunächst eine Zustandsanalyse. Diese leitet aus den Ereignissen die Abfolge der Prozesszustände ab und stellt sie dann für weitere Analysen zur Verfügung. Die Ergebnisse der Analysen werden in eigenen XML-Dateien gespeichert und können aus diesen in andere Formate übersetzt werden, um mit externen Programmen wie Gnuplot grafische Darstellungen zu erzeugen. Die Verlaufsdarstellung der Prozesszustände (siehe Abb. 4) wird derzeit im Programm selbst erzeugt, da es bislang keine Programme gab, die aussagekräftige Grafiken dieser Art erzeugen konnten. Allerdings wurde LTTV inzwischen so weit entwickelt, dass seine Nutzung für OSOBS realistisch ist. Die Entwicklung eines entsprechenden Exportwerkzeugs ist Bestandteil aktueller Arbeiten.

Universeller hybrider Systembeobachter für Echtzeitsysteme IRQ0

ruhend

Hardware-IR

laufend

CAN-Receive

lauff¨ ahig

Interface

blockiert

117

IR-Verdr¨ angung

Init

nicht laufende Gruppe

Eth0-Gruppe #Idle

t

Abb. 4: Aktivitätsdiagramm einer Beispielanwendung: senkrechte Linien sind erfasste Ereignisse (Zeitstempel und Ereigniscodes hier ausgeblendet); IRQ0 ist die Interruptleitung des externen CAN-Controllers

4 Messungen Ein wesentliches Argument für die Nutzung eines hybriden Systembeobachters ist seine Effizienz. Es wurde daher zunächst unter RTOS-UH die Laufzeit der Instrumentierung genauer untersucht. Für Linux stehen präzise Messungen noch aus, angenäherte Werte liegen aber bereits vor. Typische Werte für die Beeinflussung eines Echtzeitsystems lassen sich nicht angeben, da es keine typische Software gibt, die den Durchschnitt möglicher Anwendungen repräsentiert. Zudem hängt der Einfluss von der Dichte der Instrumentierung ab. Allerdings kann man Werte für die Instrumentierungspunkte angeben und diese ins Verhältnis zum eigentlichen Code der Anwendungen bzw. des Betriebssystems setzen. Die Untersuchungen wurden auf einem Rechner mit einer MPC7447-CPU (PowerPC) mit 1 GHz Taktfrequenz durchgeführt, der Datenaufnehmer ist über den cPCIBus mit 33 MHz angeschlossen. Auf diesem System beträgt die Ausführungszeit für einen Instrumentierungspunkt unter RTOS-UH 14ns, was länger ist, als für fünf Befehle zunächst zu erwarten wäre. Die Verlängerung erklärt sich daraus, dass Datenabhängigkeiten zwischen den Befehlen die Prozessorpipeline ineffizienter werden lassen und zudem der PCI-Speicherbereich des Systems nicht im Cache repräsentiert ist. Messungen an Prozessen zeigen, dass sich ihre Laufzeit nur um die Laufzeit der Instrumentierungspunkte verlängert und keine Nebeneffekte auftreten; die Beeinflussung ist demnach vorhersagbar. Unter Linux waren Messungen mit gleicher Präzision noch nicht möglich, aber eine Analyse des Maschinencodes lässt nur geringfügige Verlängerungen über die den acht weiteren Befehlen entsprechende Zeit hinaus erwarten. Der C-Compiler vermischt teilweise die Instrumentierungspunkte mit umgebendem Code und erhöht damit die Effizienz durch Ausnutzung der Parallelität. Die gemessene Dauer ist klein gegenüber der Laufzeit vieler Algorithmen, aber nicht vernachlässigbar. Ihrem Einfluss sind jedoch Grenzen gesetzt: Nimmt man an, dass die maximal mögliche Ereignisrate von 1,25 Mio. Ereignissen/s allein aus der Software stammt, ergeben sich pro Sekunde maximal 17, 5ms CPU-Zeit für die Instrumentierung, was 1, 75 % entspricht.

118

B. Pietsch

Einen mit OSOBS erfassten Ablauf in einer Anwendung unter RTOS-UH zeigt Abb. 4; die üblicherweise genutzten Farben für die Zustände wurden für den Druck durch Schraffuren ersetzt. In dieser Darstellung erkennt man sehr leicht nicht nur den jeweils aktiven Prozess, sondern auch die Art der Inaktivität der übrigen Prozesse. So erkennt man, dass der Prozess CAN-Receive nach dem Interrupt des CAN-Controllers (mit einem grauen Dreieck gekennzeichnet) und der entsprechenden Behandlungsroutine nicht neu anläuft, sondern nur aus einer Blockierung befreit wird; Init hingegen wird von Interface aus dem Ruhezustand heraus aktiviert. Ein weiteres Merkmal der Analyse ist die Möglichkeit, Prozessgruppen zu bilden (im Bild für die Systemdämonen der Ethernet-Schnittstelle 0 gezeigt). Diese Funktion erlaubt es, die Verteilung der Aktivität auf funktional zusammenhängende Gruppen darzustellen. Zudem bleiben auf diese Weise Diagramme übersichtlich, wenn nur wenige Prozesse für eine Analyse relevant sind und dennoch die Aktivität insgesamt verfolgbar bleiben soll.

5 Zusammenfassung und Ausblick Dieser Beitrag präsentiert den hybriden Systembeobachter OSOBS, der mit Hilfe instrumentierter Software und speziell entwickelter Hardware Abläufe in Echtzeitsystemen effizient verfolgen kann. Der modulare Hardwareaufbau erlaubt eine flexible Anpassung an verschiedene Rechnersysteme und ermöglicht auch die Beobachtung peripherer Einheiten. Die erhaltenen Daten können numerisch und grafisch unter verschiedenen Aspekten analysiert werden. Künftige Arbeiten umfassen Leistungssteigerungen in der Hardware, die Erweiterung der Analysefähigkeiten in der Software sowie die vollständige Implementierung in Linux/Xenomai. Zusätzlich sind die Einbindung von LTTV und die Erweiterung der Instrumentierung auf die Anwendungsebene geplant.

Literaturverzeichnis 1. Wolter, B.: Messung der Dienstgüte von Echtzeitbetriebssystemen durch Walsh-Korrelation, Dissertation, VDI, 2002 2. Hennessy, J.; Patterson, D.: Computer Architecture – A Quantitative Approach, Morgan Kaufmannn Publishers, 2003 3. IEEE-ISTO: The Nexus 5001 Forum Standard for a Global Embedded Processor Debug Interface, Version 2.0, 2003 4. Linux Trace Tool next generation,  5. Haban, D.; Shin, K.: Application of Real-Time Monitoring to Scheduling Tasks with Random Execution Times, IEEE Transactions on software engineering, Vol.16, 1990 6. Copetti, L., Cadamuro, J., Renaux, D. et al. : MIMO - A Hybrid Monitor for Embedded RealTime Systems, 9th Workshop on Real-Time Systems, 2007     7. Datenlogger RTBx, 8. Projekt PCI bridge auf   

Echtzeitverhalten durch die Verwendung von CPU Stubs: Eine Erweiterung von Dynamic Performance Stubs Peter Trapp, Christian Facchi und Markus Meyer Institut für Angewandte Forschung Hochschule für angewandte Wissenschaften FH Ingolstadt           

Zusammenfassung. Dynamic Performance Stubs realisieren ein Framework zur Simulation des Performanzverhaltens von Softwaremodulen und Funktionen. Sie können für eine Kosten-Nutzen-Analyse einer potentiellen Performanzoptimierung verwendet werden. Dies führt zu einer ergebnisorientierten Optimierung. Ebenso ist es möglich versteckte Flaschenhälse und die wichtigsten Optimierungskandidaten zu identifizieren. Dieser Bericht beschreibt CPU Stubs im Detail und evaluiert Einsatzmöglichkeiten, um CPU gebundene Flaschenhälse zu optimieren. Durch die Optimierung wird das Einhalten von harten oder weichen Echtzeitbedingungen ermöglicht.

1 Einleitung Dynamic Performance Stubs werden in [12] definiert. Sie können verwendet werden, um versteckte Flaschenhälse zu identifizieren. Weiterhin kann eine Kosten-NutzenAnalyse durchgeführt werden, da eine Evaluierung des Optimierungspotentials möglich ist. Die grundlegende Idee bei Dynamic Performance Stubs ist eine Kombination von Software Performanzoptimierung [4–6, 8] von existierenden Modulen oder Funktionen und Stubbing-Mechanismen bekannt aus dem Softwaretestbereich [2, 7, 9]. Das Performanzverhalten eines potentiellen Flaschenhalses (Component Under Study, CUS) wird evaluiert und durch einen Softwarestub ersetzt. Dieser Stub simuliert verschiedene Performanzverhalten. Somit kann das Verhalten der Software (Software Under Test, SUT) abhängig von verschiedenen Optimierungsstufen analysiert werden. Dieser Anwendungsfall beschreibt die Möglichkeit, ein einzelnes Modul oder eine Funktion zu ersetzen und wird im folgenden als „lokal” bezeichnet. Hierfür muss ein „lokaler Stub” erstellt werden. Die Performance Simulation Functions (PSF) können darüber hinaus verwendet werden, um das Gesamtsystemverhalten zu beeinflussen. Hierbei muss ein Softwaremodul erstellt werden, welches „global” mit dem System interagiert. Diese Art von Stubs werden als „globaler Stub” bezeichnet. Abbildung 1 zeigt das Design und die Interaktionen zwischen einem realen System und den Dynamic Performance Stubs. Die ausgefüllten Pfeilenden beschreiben eine Erweiterung der eigentlichen Funktion durch das Modul. Die nicht ausgefüllte Pfeilspitze zeigt die Ersetzung des Flaschenhalses durch den Stub. Der gestrichelte Block stellt eine

120

P. Trapp, C. Facchi, M. Meyer

Abb. 1: Interaktionen von „Dynamic Performance Stubs”

zusätzliche Funktionalität bereit und wird nicht im Sinne einer Ersetzung des Moduls durch einen Stub verwendet. Der Aufbau der Dynamic Performance Stubs besteht aus den in Abbildung 1 dargestellten Elementen: – Simulated Software Functionality (SSF) Die Simulated Software Functionality stellt das rein funktionale Verhalten des Flaschenhalses während des Performanztests nach, um ein lauffähiges System zu erhalten. – Performance Simulation Functions (PSF) Performance Simulation Functions werden eingesetzt, um das Performanzverhalten der Software zu simulieren. Das Performanzverhalten des Stubs kann hierbei verändert und evaluiert werden. Die Performance Simulation Functions sind, je nach Einsatzbereich, in folgende Kategorien unterteilt: • CPU • Memory • I/O • Network – Performance Measurement Functions (PMF) Um eine Basisfunktionalität für Performanzmessungen innerhalb der Stubs zur Verfügung zu stellen, wurde das Framework um die Performance Measurement Functions erweitert. Diese werden in erster Linie auf bereits im System bestehende Messmöglichkeiten zurück geführt. – Calibration Functions (CF) Um die Funktionalität der Performance Simulation Functions zu gewährleisten und diese an das jeweilige System anzupassen existieren die sogenannten Calibration Functions. Der Aufbau und die Einsatzmöglichkeiten von Dynamic Performance Stubs wurden in [12] detaillierter beschrieben.

Dynamic Performance Stubs

121

CPU Stubs dienen der Simulation des zeitlichen Verhaltens von Softwaremodulen und Funktionen. Die Funktionsweise, Realisierungsmöglichkeiten sowie deren Validierung wurden bereits in [11] dargestellt. Im weiteren Verlauf dieses Berichts werden die CPU Stubs kurz erläutert. Die Methodik aus [11] zeigt primär eine Möglichkeit zur Erstellung von CPU Stubs. In diesem Bericht wird die Methodik zur Optimierung verfeinert, die bisher nur im Ansatz festgelegt war. Abschließend werden die CPU Stubs anhand einer Fallstudie, die zur Optimierung der LTE (Long Term Evolution) Telekommunikationssoftware von Nokia Siemens Networks durchgeführt wurde, validiert.

2 CPU Stubs CPU Stubs dienen der Simulation des zeitlichen Verhaltens eines durch die CPU verursachten Flaschenhalses. Eine CPU kann sich entweder im aktiven oder im wartenden Zustand befinden. Ist die CPU im wartenden Modus wird lediglich der „Idle”-Prozess ausgeführt. Dieser Zustand muss nicht durch CPU Stubs simuliert werden. Die Anforderungen an CPU Stubs definieren sich durch die Zustände, die ein Prozess aus Sicht der CPU annehmen kann. Diese sind: In Ausführung und Unterbrochen. Der erste zu simulierende Zustand ist in Ausführung. Ein Prozess in Ausführung belegt vollständig die CPU unabhängig von der Aufgabe. Der Zustand in Ausführung wird im Allgemeinen als „Running” bezeichnet (vgl. [10]). Der zweite zu simulierende Zustand ist Unterbrochen, im weiteren Verlauf als „Delayed” bezeichnet. In diesem wird der Prozess nicht von der CPU ausgeführt. Dem Prozessmodell nach [10] entspricht dies den Zuständen: „Blocked” und/oder „Ready”. Ein Prozess wird aus dem Zustand „Running” in den Zustand „Blocked” überführt, wenn seine weitere Arbeit von temporär nicht verfügbaren Ressourcen abhängt. Ist der Prozess nicht mehr blockiert, wechselt der Scheduler den Zustand des Prozesses von „Blocked” auf „Ready”. Sobald eine freie CPU zur Verfügung steht, wird der Prozess weiter ausgeführt (Zustand „Running”). Damit das zeitliche Verhalten von Funktionen oder Modulen durch CPU Stubs simuliert werden kann, müssen diese die Zustände „Running” und „Delayed” simulieren können. Im Folgenden wird eine mögliche Realisierung vorgestellt: Running: In diesem Zustand wird der Prozess von der CPU ausgeführt. Dies kann mit einer sogenannten „busy loop” realisiert werden. In [11] wurde eine mögliche Implementierung vorgestellt, sowie die Simulationsmöglichkeiten validiert und diskutiert. Dies entspricht den „system influencing” CPU-PSF aus [11]. Delayed: Dies beschreibt den Zustand des Prozesses, in dem der Prozess nicht von der CPU ausgeführt wird und beinhaltet die zwei Zustände: „Blocked” und „Ready”. Der Übergang aus dem aktiven („Running”) in den blockierten Zustand („Blocked”) sowie die entsprechende Zeitdauer im „Blockierten” Zustand kann mittels eines „sleep” Befehls realisiert werden, beispielsweise kann der „μsleep” Befehl aus „unistd.h” in UNIX-ähnlichen Umgebungen verwendet werden. Dies entspricht den „system noninfluencing” CPU-PSF aus [11]. In diesem Fall wartet der Prozess eine festgelegte Zeitdauer. Nach dieser Wartezeit ändert der Scheduler den Zustand des Prozesses von

122

P. Trapp, C. Facchi, M. Meyer

„Blocked” auf „Ready”. Die Zeitspanne, in der sich der Prozess in diesem Zustand befindet, ist abhängig von der Auslastung der CPU im System und hängt von vielen Faktoren, wie z. B. der Priorität des Prozesses, ab. Im Benutzer-Modus, in dem der CPU Stubs i. d. R. verwendet wird, kann ein Wechsel aus dem Zustand „Ready” in den Zustand „Running” nicht erzwungen werden. Es besteht lediglich die Möglichkeit, die Wahrscheinlichkeit, aktiviert zu werden zu erhöhen, beispielsweise in dem der Prozess eine höherer Priorität bekommt. Eine Validierung der Funktionsweise von CPU Stubs sowie mögliche Anwendungsfälle wurden detailliert in [11] diskutiert.

3 Methodik Im Folgenden wird eine Methodik zur Erstellung und Anwendung von CPU Stubs dargestellt. 1. Bestimmung des CPU Flaschenhalses (CUS): Als erster Schritt bei einer Performanzoptimierungsstudie muss zunächst die Software auf Flaschenhälse überprüft werden [6]. Der vermeintliche Flaschenhals muss näher untersucht werden. Die hierzu gemessenen Laufzeitwerte sollten bei einer Wiederholung innerhalb eines Vertrauensintervals konstant bestimmbar sein. Besonders sollten folgende Werte deterministisch sein: t SUT ist ein Performanzindikator des Softwaremodules oder der Funktion. Dieser Wert wird benötigt, um das Performanzverhalten des Systems zu bestimmen. Häufig entspricht dies der Zeit, welche das System zur Bearbeitung einer bestimmten Aufgabe benötigt. In der Regel stellen sie einzuhaltende Echtzeitbedingungen eines Systems dar. t CUS ist die Zeitdauer, die die CUS benötigt, um eine Aufgabe vollständig zu erledigen (Wall Clock Time). Hierbei sollten bestmöglichst keine unfreiwilligen CUS ) Kontextwechsel stattfinden, damit die tatsächliche CPU Auslastung (CPUusage im weiteren Verlauf ermittelt werden kann. Die Zeitmessung kann beispielsweise mittels des Time Stamp Counters (TSC [3]) oder der Funktion „getrusage()”1 erfolgen. CUS tbusy ist die Zeitdauer, die das CUS die CPU belegt (CPU time)2 , um die Aufgabe vollständig zu bearbeiten. CUS CPUusage ist die Auslastung der CPU, die innerhalb der Ausführung des Flaschenhalses, durch diesen verursacht wird. Die Auslastung kann aus dem VerhältCUS und der Gesamtausführungsdauer t CUS berechnet wernis der CPU Zeit tbusy den (Gleichung 1) oder mit Hilfe verschiedener Tracingtools, beispielsweise LTTng3 , gemessen werden. CUS = CPUusage 1 2 3

CUS tbusy

t CUS

(1)

In UNIX-basierten Umgebungen kann getrusage mittels Einbinden des Headerfiles sys/resource.h mit der Programmiersprache C verwendet werden. Die CPU Zeit enthält die Zeit, welche der Prozess sowohl im Benutzermodus als auch im Systemmodus verbringt. Linux Trace Toolkit Next Generation @ http://ltt.polymtl.ca/

Dynamic Performance Stubs

123

CUS von eins bedeutet hierbei, dass die gesamte Zeit, die Ein Wert für CPUusage der Flaschenhals benötigt, zur Bearbeitung der Aufgabe verwendet wird. Ein CUS Wert für CPUusage kleiner eins bedeutet, dass der Flaschenhals Teile seiner Gesamtausführungsdauer im blockierten Zustand verbringt und der Prozess auf weitere Ereignisse wartet.

2.

3.

4.

5.

Dieser Schritt sollte mehrfach durchgeführt werden, um eine statistische Verteilung der benötigten Werte berechnen zu können. Wenn nur kleinere Schwankungen auftreten, kann zum nächsten Schritt übergegangen werden. Validierung des CPU Flaschenhalses. In diesem Schritt wird die Ausführungszeit des Flaschenhalses durch Hinzufügen der system influencing CPU-PSF vergrößert, sowie folgende Zeiten gemessen: t CUS und t SUT . Steigen die Ausführungszeiten des Modules oder der Funktion durch das Vergrößern der Zeiten an, so ist dies ein Hinweis darauf, dass es sich um einen CPU Flaschenhals handelt. Sollte sich die Gesamtausführungszeit der Software nicht ändern, liegt voraussichtlich kein CPU Flaschenhals vor. Dieser Schritt ist optional und dient in erster Linie einer Vermeidung von Aufwand, der z. B. durch die Erstellung des CPU Stubs entstehen würde. Untersuchung des CPU Flaschenhalses. Hierfür wird zunächst die Auslastung der CUS bei unCPU durch den Flaschenhals näher untersucht. Liegt der Wert von CPUusage gefähr eins, benötigt der Flaschenhals die CPU während seiner gesamten Laufzeit. CUS In diesem Fall kann mit Schritt 4 fortgefahren werden. Ist der Wert von CPUusage deutlich kleiner als eins, muss das zeitliche Verhalten des Flaschenhalses, beispielsweise mittels LTTng, näher untersucht werden. Hierfür müssen zusammenhängende Arbeits- und Wartezeiten identifiziert werden. Das weitere Vorgehen, das zudem individuell stark variiert, wird aus Platzgründen in dieser Methodik nicht näher spezifiziert. Erstellung eines Flat CPU Stub. Hierfür muss das funktionale Verhalten des Flaschenhalses für die vorliegenden Testfälle untersucht und mittels der Simulated Software Functionality nachgestellt werden [12]. Nachdem das funktionale Verhalten des Stubs validiert wurde, kann dieser für die weitere Auswertung verwendet werden. Optimierungspotential ermitteln. Nachdem sich in Schritt 3 der Verdacht erhärtet hat, dass es sich bei der vorliegenden Software um einen CPU Flaschenhals handelt, wird in diesem Schritt das maximale Optimierungspotential ermittelt. Hierfür verwendet man den erstellten Stub und führt die Performanzmessung unter den gleichen Testbedingungen erneut aus und misst t STUB f lat . Dies ist die Zeit, welche in einem Flat CPU Stub benötigt wird. Der Wert entspricht der Zeit, welche durch die Simulated Software Functionality benötigt wird, um die Funktionalität der Funktion zu simulieren. Die in Gleichung 2 ermittelte Zeit wird im weiteren Verlauf für die Erstellung von Stubs zur Analyse des Systems verwendet. t per f _gain = t CUS − t STUB f lat

(2)

124

P. Trapp, C. Facchi, M. Meyer

Hierfür wird von der Gesamtzeit, die das System für die Ausführung des Flaschenhalses benötigt, die Zeit eines leeren Stubs subtrahiert. Der ermittelte Wert t per f _gain ist annähernd der maximal mögliche Gewinn, der bei einer Optimierung des Flaschenhalses erreicht werden kann. Ist der mögliche Gewinn nur sehr gering im Verhältnis zur Gesamtzeit t SUT , macht eine weitere Optimierung des Flaschenhalses nur bedingt Sinn, beispielsweise beim Vorliegen von Timingproblemen, die die Ausführung verzögern. Hierfür muss die Software erneut, wie in Schritt 1 beschrieben, unter Beachtung der neuen Kenntnisse untersucht werden. Ist ein großer Gewinn bei der Optimierung zu erwarten, kann zum nächsten Schritt übergegangen werden. 6. Der Flat CPU Stubs aus Schritt 5 wird hier um die system non-influencing Funktionalität erweitert. Die Dauer, welche hierfür verwendet wird, bezieht sich auf die Gesamtausführungszeit des ursprünglichen Flaschenhalses und kann mittels Gleichung 2 berechnet werden. STUB Nach erneuter Ausführung des Performanztests und Messungen der Zeiten tidle SUT und tidle können verschiedene Aussagen über die Interaktionen der Funktionen oder Module getroffen werden, beispielsweise können verschiedene zeitliche Abhängigkeiten identifiziert werden. Aus Platzgründen werden diese hier nicht genauSTUB und t SUT entsprechen hierbei den Zeiten, die im Stub bzw. er beschrieben. tidle idle SUT unter Verwendung der system non-influencing PSF gemessen werden. 7. Abschätzung des Optimierungsaufwandes. Nachdem das Optimierungspotential bereits in Schritt 5 evaluiert wurde, beschäftigt sich dieser Schritt mit dem notwendigen Aufwand, um dieses Optimierungspotential zu realisieren. Hierfür wird die Zeit ermittelt, um die der Flaschenhals mindestens optimiert werden muss, damit die Ausführungszeit für den Flaschenhals dem minimalen Wert t per f _gain entspricht. Dies kann erreicht werden, indem ein Busy CPU Stub erstellt wird. Der Stub aus Schritt 5 wird um die system influencing Funktionalität erweitert. Anschließend wird der eingestellte Wert sukzessiv erhöht, solange die eingestellte Zeit kleiner als das Optimierungspotential t per f _gain ist. Mit Hilfe der ermittelten Werte kann eine Kosten-Nutzen-Analyse durchgeführt werden. Die Kosten für die Optimierung müssen unter Beachtung des notwendigen Optimierungsaufwands geschätzt werden. Weitere Auswertemöglichkeiten sowie verschiedene mögliche Arten von Graphen werden aus Platzgründen hier nicht weiter diskutiert. 8. Optimierung und Validierung. Nachdem der Aufwand sowie der Nutzen einer möglichen Optimierung bekannt ist, kann die Optimierung des Flaschenhalses durchgeführt werden. Abschließend wird die Performanz des gesamten Systems nach der Optimierung validiert. Sollten diese den einzuhaltenden Echtzeitbedingungen nicht entsprechen, kann mit Schritt 1 fortgefahren werden. Sind alle Performanzanforderungen erfüllt, sind keine weiteren Optimierungsschritte notwendig.

4 Fallstudie Die hier beschriebene Fallstudie wurde im Rahmen einer Performanzoptimierung des bei Nokia Siemens Networks entwickelten Telekommunikationselements eNB (evol-

Dynamic Performance Stubs

125

ved Node B) des Systems LTE (Long Term Evolution) durchgeführt. Eine Einführung in LTE ist in [1] gegeben. Die dargestellten Ergebnisse wurden aus Datenschutzgründen in einer Testumgebung ermittelt. Ein Vergleich zwischen der Testumgebung und der Zielplattform zeigte ein sehr ähnliches Performanzverhalten. Die statistischen Schwankungen der Messergebnisse sind jedoch in der Testumgebung stärker vorhanden. Dies erklärt sich durch die Tatsache, dass in der Testumgebung mehrere Tests gleichzeitig stattfinden können. Für die Durchführung und Auswertung der Fallstudie wurde die von Nokia Siemens Networks entwickelte Performanztestsoftware verwendet. Als Testfall wurde der Aufbau einer Verbindung gewählt. 4.1 Ausgangssituation Als Flaschenhals wurde eine Funktion, die die Daten zu den bestehenden Verbindungen verwaltet, identifiziert. Für weitere Messungen wurde ein Testfall spezifiziert, um das Verhalten der Funktion bei Verbindungen näher untersuchen zu können. Hierbei werden 400 Verbindungen aufgebaut. Mit t SUT wurde die benötigte Zeit für den vollständigen Verbindungsaufbau bestimmt. Die Zeit, die das System zur Verwaltung der Verbindungen benötigt, wurde mit t CUS bezeichnet.

(a) Vergleich SUT und CUS

(b) Zeitverhalten CUS

Abb. 2: Vergleich von SUT und CUS (a) und Zeitverhalten von CUS (b) der original Funktion In Abbildung 2a ist die benötigte Dauer für t SUT und t CUS dargestellt. Die Y-Achse zeigt hierbei die Zeit in Mikrosekunden, die das System bzw. der Flaschenhals benötigt, in Abhängigkeit der Anzahl bereits bestehender Verbindungen (X-Achse). Die Auswertung der Kurven ergab, dass mit steigender Anzahl die benötigte Dauer für einen weiteren Verbindungsaufbau ansteigt. Anschließend wurden, wie in Schritt 1 in Kapitel 3 beschrieben, die Schwankungen der einzelnen Werte bestimmt. Abbildung 2b zeigt hierbei, dass die Ausführungszeiten für t CUS nur gering schwanken. Die dargestellten Graphen entsprechen fünf voneinander unabhängigen Testläufen. Die Achsen

126

P. Trapp, C. Facchi, M. Meyer

entsprechen denen aus Abbildung 2a. Die teilweise vorhanden Spitzen sind bei den Messungen auf dem Zielsystem nicht so stark vorhanden. Ähnlich verhalten sich die Zeiten für t SUT , diese werden jedoch aus Platzgründen nicht näher erläutert. 4.2 CPU Stub Wie in Schritt 5 in Kapitel 3 beschrieben wurde die minimale Ausführungszeit t STUB f lat , die mit einem CPU Stub simuliert werden kann, bestimmt. Diese schwankte mit minimalen Abweichungen um den Mittelwert 11μs. Der Wert stellt im Vergleich zu den gemessenen Werten in der Ausgangssituation, vor allem bei hoher Anzahl der Verbindungen, eine signifikante Verbesserung dar. Damit war das in Kapitel 3 in Schritt 5 definierte Optimierungspotential t per f _gain groß genug für die weitere Untersuchung und Optimierung des Flaschenhalses.

Abb. 3: Messung des Optimierungspotentials

Abb. 4: Messung der Systemabhängigkeiten

Abbildung 3 zeigt das simulierte Zeitverhalten des Systems unter Einsatz eines Flat Stubs. Auf der X-Achse ist die Anzahl der aufgebauten Verbindungen zu sehen. Die Y-Achse zeigt die benötigte Zeit in Mikrosekunden. Durch den Einsatz des CPU Stubs wurde das Zeitverhalten des CUS so verändert, dass die Anzahl der Verbindungen nahezu keine Rolle mehr für die Gesamtzeit spielt. Eine erste Codeanalyse ergab, dass eine Optimierung durch Änderungen am Quellcode möglich war. Deswegen entfiel die in Schritt 6 aus Kapitel 3 erwähnte Analyse der zeitlichen Abhängigkeiten der Softwarefunktionen. Um den in Kapitel 3 in Schritt 7 beschriebenen Optimierungsaufwand festzustellen, wurde die in der Performance Simulation Function verbrauchte Zeit mit jeder aufgebauten Verbindung linear erhöht. Die Auswertung der Messung ergab, das t SUT mit steigendem Zeitverbrauch des Stubs anstieg. Die vom SUT benötigte Zeit stieg jeweils um das im Stub hinzugefügte Zeitintervall. Der Zusammenhang ist in Abbildung 4 dargestellt. Die Achsen entsprechen denen aus Abbildung 2. Die untere Linie stellt den

Dynamic Performance Stubs

127

zeitlichen Verlauf des Stubs dar. Die obere Linie entspricht dem des SUTs. Der Verlauf der Kurven bedeutet, dass die im SUT benötigte Zeit über das gesamte gemessene Zeitintervall direkt von t CUS abhängt. Ein Performanzgewinn im Flaschenhals hat damit zu jeder Zeit auch einen Performanzgewinn im System zur Folge. 4.3 Optimierte Funktion Aus den durch den Einsatz der CPU Stubs gewonnene Informationen konnte der Quellcode optimiert werden. Nach der Optimierung stellte sich ein annähernd konstanter Zeitverlauf für die benötigte Zeit zum Verwalten der Verbindungen ein. Auch die Gesamtzeit des SUT zeigt nach den Optimierungsschritten nun ebenfalls einen fast konstanten Verlauf. Dies entspricht in etwa dem Verhalten wie in Abbildung 3 dargestellt. Selbstverständlich konnte nicht das gesamte Optimierungspotential t per f _gain erzielt werden. Die erbrachte Optimierung stellt eine signifikante Verbesserung des Zeitverhaltens der Funktion dar und wirkt sich verstärkt bei steigender Anzahl an Verbindungen aus.

5 Fazit und Ausblick In diesem Bericht wurde gezeigt, dass das CPU Performanzverhalten eines Flaschenhalses simuliert werden kann. Mit Hilfe dieser Simulation können die Auswirkungen verschiedener Optimierungsstufen auf das Performanzverhalten des Systems evaluiert werden und somit eine Kosten-Nutzen-Analyse realisiert werden. Hierfür wurde zunächst eine Methodik zur Erstellung und Anwendung von CPU Stubs diskutiert und anhand einer Fallstudie evaluiert. Im Rahmen der Fallstudie konnte durch die Optimierung das Einhalten von Echtzeitbedingungen realisiert werden. Auch zeigte die Fallstudie, dass komplexe Abläufe, wie das Hinzufügen und Auslesen von Informationen aus einer Datenbasis, gestubbed werden können. Die vorgestellte Methodik wurde aus Platzgründen gekürzt. Im Besonderen kann die hier beschriebene Methodik in erster Linie für rein zeitgebundene Systeme eingesetzt werden. Weiterhin können verschiedene Evaluierungsschritte ergänzt werden: – Schritt 6: In diesem Schritt ist eine zusätzliche Auswertung bezüglich der Ressource CPU möglich. – Schritt 7: Hierbei können Abhängigkeiten des Flaschenhalses in Bezug auf nachfolgende Funktionen evaluiert werden. Dies soll nur einen kleinen Ausblick über Erweiterungsmöglichkeiten der Methodik darstellen.

6 Danksagung Diese Forschung wird von Nokia Siemens Networks (NSN) maßgeblich gefördert. Die Autoren bedanken sich bei der LTE Gruppe, besonders bei Rudolf Bauer, Oliver Korpilla, Jörg Monschau, Helmut Voggenauer and Jochen Wessel als Stellvertreter für die exzellente Unterstützung und Beiträge zu dieser Forschungsarbeit.

128

P. Trapp, C. Facchi, M. Meyer

Wir möchten uns bei dem Software Technology Research Laboratory (STRL) der De Montfort University Leicester (UK), hierbei besonders bei François Siewe und Hussein Zedan, für das Bereitstellen einer adäquaten Forschungsumgebung bedanken.

Literaturverzeichnis 1. Al-Shahrani, A., und Al-Olyani, H.: LTE. online:             , 2008. Juni 2009. 2. Bertolino, A., und Marchetti, E.: Software Engineering: The Development Process - A Brief Essay on Software Testing, volume 1, chapter 7, pages 393–411. John Wiley & Sons, Inc., 3te Ausgabe, 2005. 3. Etsion, Y., und Feitelson, D.: Time Stamp Counters Library - Measurements with Nano Seconds Resolution, 2000. 4. Fortier, P. J., und Michel, H. E.: Computer Systems Performance Evaluation and Prediction, volume 1. Digital Press, Burlington, 2003. 5. Gunther, N. H.: The Practical Performance Analyst. McGraw-Hill Education, 1998. 6. Jain, R.: The art of computer systems performance analysis. Wiley and sons, Inc., 1991. 7. Liggesmeyer, P.: Software-Qualität : Testen, Analysieren undVerifizieren von Software. Spektrum Akademischer Verlag GmbH, Berlin, 2002. 8. Lilja, D. J.: Measuring Computer Performance: A Practioner’s Guide. Cambridge University Press, New York, 2000. 9. Sommerville, I.: Software Engineering. Addison-Wesley, 6te Ausgabe, 2001. 10. Tanenbaum, A. S.: Modern Operating Systems. Prentice-Hall, Inc., 2te Ausgabe, 2001. 11. Trapp, P., und Facchi, C.: How to Handle CPU Bound Systems: A Specialization of Dynamic Performance Stubs to CPU Stubs. In CMG 08: International Conference Proceedings, Seiten 343 – 353, 2008. 12. Trapp, P., und Facchi, C.: Performance Improvement Using Dynamic Performance Stubs. Technical Report 14, Fachhochschule Ingolstadt, August 2007.

Protokollanalyse und Informationsflussverfolgung zur Fehlerdiagnose in verteilten Echtzeitsystemen Eugen Noak, Silvije Jovalekic, Heinrich Grochowski Labor für Softwaretechnik und Echtzeitsysteme Hochschule Albstadt-Sigmaringen Jakobstraße 6, D-72458 Albstadt

Zusammenfassung. Bei vernetzten wertdiskreten Echtzeitsystemen treten in der Praxis Fehler auf, obwohl die einzelnen Komponenten fehlerfrei funktionieren. Automatisierte Testverfahren helfen solche Fehler zu entdecken. Zur Beschreibung der Testfälle solcher Systeme wird der zeitbehaftete Ursache-WirkungsGraph verwendet. Mit den graphischen Testfällen wird der Informationsfluss im verteilten System verfolgt und auf Inhalt und Zeitbedingungen überprüft. Somit können die Knoten lokalisiert werden, die an einem Fehlverhalten beteiligt sind. Bei der erweiterten Informationsflussverfolgung greift das Verfahren auf die Konfigurationsdaten des Testobjektes zurück. Mit symbolischen Testplandaten und der Filterung der Rohdaten wird die Informationsflussverfolgung auf einem hohen Abstraktionsniveau durchgeführt. Die Fehlersuche wird durch Darstellungen des Busverkehrs mittels Ereignisliste und Impulsdiagramm wesentlich erleichtert.

1 Einleitung Zur Sicherstellung der Qualität während der Entwicklung und des Betriebes eines Produktes sind der Test und die Diagnose von großer Bedeutung. Für den automatisierten Test der Softwaremodule gibt es sowohl für den Black-box als auch für den White-box Test eine Vielzahl von Methoden und Werkzeugen [1]. Bei eingebetteten verteilten Echtzeitsystemen wird zunehmend die Methode Hardware-in-the-Loop eingesetzt. Dabei wird ein reales Testobjekt mit einer simulierten Umgebung des technischen Prozesses verwendet. Die Beschreibung der Testfälle erfolgt dabei häufig durch Erweiterungen von Skriptsprachen (PERL, Basic). In komplexen Telekommunikationssystemen wird die Testbeschreibungssprache TTCN-3 verwendet. Für mittlere und kleinere Projekte, insbesondere im Bereich der Mechatronik, werden einfache graphische Verfahren wie zum Beispiel Sequenzdiagramme und Zustandsdiagramme eingesetzt [2]. Gebäudesicherungssysteme sind durch heterogene und proprietäre Netzwerke mit vielfältigen Komponenten und sehr unterschiedlichem Zeitverhalten gekennzeichnet. Das führt dazu, dass die Systemtests häufig manuell durchgeführt werden. Im Projekt STARTS (System Test Automation of Distributed Real-Time Systems) wurden Methoden und Werkzeuge für den Systemtest mit zeitbehafteten Ursache-Wirkungs-Graphen entwickelt. In diesem Aufsatz beschreiben wir Verfahren, die zusätzlich eine strukturelle Beschreibung des Testobjektes voraussetzen. Mit Hilfe dieses White-box Verfahrens

130

E. Noak, S. Jovalekic, H. Grochowski

lassen sich fehlerhafte Komponenten lokalisieren. Dieses Verfahren bezeichnen wir als erweiterte Informationsflussverfolgung. In der Systemtechnik existieren bereits Methoden und Sprachen zur allgemeinen Beschreibung von Anlagen-, Steuer- und Busstrukturen, z. B. CAEX. Wir haben eine einfache Sprache zur Beschreibung der Testobjekte und darauf basierende Auswertemöglichkeiten konzipiert und entwickelt [3] [4] [5].

2 Testplanung und Testausführung 2.1 Betrachtete Klasse der Testobjekte Im Folgenden wird die Klasse von Testobjekten mit diskreten Werten betrachtet. Das System gliedert sich in ein oder mehrere zentrale Verarbeitungsknoten, die untereinander über schnelle Backbone-Busse verbunden sind. An den Feldbussen sind Bedienteile, Sensoren und Aktoren angeschlossen. Die Eingangsgrößen von den Sensoren (z. B. Bewegungsmelder) eignen sich für die Stimulation, die Ausgangsgrößen an die Aktoren (z. B. Sirenen) oder die Zustandsgrößen zwischen den Rechnerknoten (z. B. Busverkehr) eignen sich für die Beobachtung des Testobjektes. Je weiter oben das Bussystem in der Hierarchie angesiedelt ist, desto mehr steigt das Datenaufkommen und somit die erforderliche Bandbreite. Im Sensorbereich werden nur wenige Baud, im Backbonebereich werden mehrere MBaud übertragen. In der Interaktion mit dem Menschen liegen die Reaktionszeiten im 100 ms-Bereich, auch wenn die Kommunikation über mehrere Bushierarchien erfolgt. Besonders kritisch sind hier natürlich die Aktivitäten, die zu einem Fehlalarm oder schlimmer, zu einer fehlenden Alarmmeldung führen [4]. 2.2 Graphische Testplanung Zur Beschreibung der Testfälle wird der zeitbehaftete Ursache-Wirkungs-Graph verwendet. Um diskrete verteilte Systeme beschreiben zu können, wurde der boolsche Ursache-Wirkungs-Graph um Kommunikationskanäle, Zeitbedingungen und Ablaufstruktur erweitert. Die Elemente der graphischen Testplansprache sind Testprojekte, Testfälle, Testoperationen und Testübergänge. Ein Testprojekt ist eine Folge von Testfällen. Ein Testfall wird aus Testoperationen und Testübergängen aufgebaut. Jeder Testfall hat eine feste Position im Testprojekt, welche die Reihenfolge bei der Testausführung bestimmt. Abb. 1 zeigt ein Testobjekt und den Testfall »Bewegungsalarm«. Das Testobjekt besteht aus einem Bewegungsmelder und einer Lichtanzeige, die über die Kommunikationsmedien Feldbus, Sicherheitsnetzwerk und Backbone mit der Einbruchmeldezentrale verbunden sind. Mit den Messwerkzeugen wird der Nachrichtenverkehr auf den Bussen abgehört. Die Testoperation »Bewegungsmelder« wartet auf die Nachricht »Bewegung« vom Kanal »Feldbus«. Trifft in der Testoperation »Lichtanzeige« die Nachricht »Licht-ein« vom Kanal »Sicherheitsnetzwerk« zum Zeitpunkt t < T1 + T2 nach dem Eintreffen der Nachricht »Bewegung« ein, so ist der Testfall erfolgreich (PASS), ansonsten nicht erfolgreich (FAIL). Der Datenaustausch zwischen den Rechnerknoten des Testobjektes wird im Graph durch Testoperationen dargestellt.

Protokollanalyse und Informationsflussverfolgung in verteilten Echtzeitsystemen

Backbone

131

Netzwerkinterface Sicherheitsnetzwerk Messwerk -zeug

Feldbus Lichtanzeige

Messwerkzeug

Bewegungsmelder

Feldbus

Backbone

Sicherheitsnetzwerk

Aktor Testobjekt

Sensor

Bewegung

Licht-ein

Testfall »Bewegungsalarm«

Bewegungsmelder Kanal: Feldbus Nachricht: Bewegung

T1 < 200 ms Testübergang (Zeitbedingung)

Einbruch Kanal: Backbone Nachricht: Einbruch

T2 < 300 ms

Lichtanzeige Kanal: Sicherheitsnetz.. Nachricht: Licht-ein

Testoperation

Abb. 1: Exemplarische Erläuterung der Testplansprache

Eine Testoperation hat die Aufgabe, eine spezifizierte Nachricht von einem Kommunikationskanal zu empfangen oder an den Kommunikationskanal zu senden. Ein Testfall kann durch Sequenzen, bedingte Verzweigungen, UND/ODER-Zusammenführungen, parallele Zweige, Rückkopplungen und Testfallverweise beschrieben werden. Zwei Testoperationen werden über einen Testübergang verbunden. Die Zeitspezifikation eines Testübergangs enthält die maximale und/oder die minimale Zeitangabe. Dadurch wird die Zeitspanne oder die Zeitfrist für den Testübergang spezifiziert. Dem Testübergang kann eine Bedingung zugeordnet werden, bei deren Zutreffen der Übergang stattfindet. Die Testplanung mittels zeitbehaftetem Ursache-Wirkungs-Graphen ermöglicht bei der Testausführung den Informationsfluss im verteilten System auf korrekten Inhalt und zeitliche Bedingungen zu überprüfen. Dieses Verfahren bezeichnen wir als Informationsflussverfolgung [4]. 2.3 Betriebsarten der Testausführung Bei der Testausführung findet der Vergleich zeitabhängiger Sollwerte mit den erfassten Istwerten statt. Im »Aktiven Modus« wird das Testobjekt über die Kommunikationskanäle mit definierten Nachrichten stimuliert und die korrekte Reaktion des Testobjektes anhand vorgegebener, zu erwartender Nachrichten und Zeitbedingungen überwacht. Diese Betriebsart ist für den Test während der Entwicklung und Integration geeignet. Beim »Beobachtermodus« wird auf Nachrichten vom Testobjekt gewartet und nach Testfällen mit entsprechenden Startoperationen gesucht. Existiert ein passender Testfall, so wird dieser ausgeführt. Diese Betriebsart ist besonders für die Diagnose während des Systemeinsatzes geeignet. Hier kann das „Standardverhalten“ eines Systems als Samm-

132

E. Noak, S. Jovalekic, H. Grochowski

lung von Testfällen festgelegt werden. Die umgekehrte Vorgehensweise, die Definition eines möglichen Fehlerzustandes als Testfall, ist ebenfalls möglich und oft einfacher.

3 Referenzmodell der Testobjektbeschreibung 3.1 Erweiterte Informationsflussverfolgung Durch Hinzufügen der Strukturinformation des Testobjektes wird das Verfahren der Informationsflussverfolgung erweitert. Dies ermöglicht ein vertieftes Testen und leichter interpretierbare Testergebnisse. In Abb. 2 sind auf der rechten Seite die Grundverarbeitungen bei der Testplanung und Testausführung dargestellt. Aus den Testszenarien formuliert der Tester die Testfälle, die in der Testplan-Datenbank abgelegt werden. Während der Testausführung wird das Testobjekt stimuliert und beobachtet, woraus dann Testberichte erstellt werden. Grammatik der Beschreibungssprache für Testobjekte

Neutrale StrukturBeschreibung des Testobjektes

Sprachspezifikation

Testobjektdaten

Sprachspezifikation

Testplanung Testszenarien

Testobjektübersetzer

Testplansprache STARTS-PLAN

Testfälle

TestplanDatenbank

Testobjekt Stimulationsdaten Testfälle Konfigurationsdaten

Beobachtungsdaten

CAE abhängige Beschreibung des Testobjektes

Testausführung

Testergebnisdaten

Testberichte

Abb. 2: Konzept der erweiterten Informationsflussverfolgung

Auf der linken Seite wird die erweiterte Informationsflussverfolgung dargestellt. Die Systemstruktur des Testobjektes wird mit dem firmenspezifischen Werkzeug ausgelesen. Diese wird dann mit dem Testobjektübersetzer in eine neutrale Beschreibung transformiert. Diese Informationen werden bei der konfigurationsabhängigen Protokollanalyse verwendet. Außerdem sollen die Testobjektdaten bei der Testplanerstellung Anwendung finden [5] [6]. 3.2 Beschreibungssprache für Testobjekte Die CAE Beschreibungen des Testobjektes sind nicht standardisiert. Um die CAEUnabhängigkeit der Testobjektbeschreibung zu ermöglichen, wurde ein Referenzmodell für Testobjekte, bestehend aus Modulen und Verbindungen definiert. Die Module beschreiben die Verarbeitungseinheiten (z. B. Bewegungsmelder). Die Verbindungen modellieren die Kommunikationswege zwischen den Verarbeitungseinheiten (z. B. serielle Schnittstelle oder Busse) [7] [8].

Protokollanalyse und Informationsflussverfolgung in verteilten Echtzeitsystemen

133

<xs:complexType name="ModuleType"> <xs:sequence> <xs:element name="Module" type="ModuleType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="Connection" type="ConnectionType" minOccurs="0" maxOccurs="unbounded"/> <xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="description" type="xs:string" use="optional"/> <xs:attribute name="address" type="xs:integer" use="optional"/> <xs:attribute name="type" type="xs:integer" use="optional"/> <xs:complexType name="ConnectionType"> <xs:sequence> <xs:element name="Module" type="ModuleType" maxOccurs="unbounded"/> <xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="system_id" type="xs:integer" use="required"/> <xs:attribute name="messwerkzeug" type="xs:string" use="optional"/> <xs:attribute name="channel" type="xs:integer" use="optional"/> <xs:attribute name="aktiv" type="xs:string" use="optional"/>

Abb. 3: Definition der Module und Verbindungen

Abb. 3 zeigt die Definition des komplexen Typs »ModuleType« zur Beschreibung der Modulsyntax. Jedes Modul kann weitere Module oder Verbindungen enthalten. Die Adressen der Module, die an einer Verbindung angeschlossen sind, sollen unterschiedlich sein. Das Attribut »type« dient der eindeutigen Identifikation des Typs eines Moduls. Der komplexe Typ »ConnectionType« dient zur Beschreibung der Verbindungssyntax. Eine Verbindung kann nur Module als Unterelemente enthalten. »System_id« spezifiziert das Protokoll einer Verbindung. Das Attribut »messwerkzeug« ist optional, da nicht jeder Verbindung ein Messwerkzeug zugeordnet sein muss.

3.3 Beschreibung des Testobjektes Abb. 4 zeigt einen Ausschnitt eines Einbruchmeldesystems mit zugehöriger Systemstruktur-Information. Es besteht aus einer Einbruchmeldezentrale und zwei Sensoren, die an einen Feldbus angeschlossen sind. Das Feldbuskoppelmodul dient als Übersetzer zwischen dem internen Bus und dem Feldbus. Rechts im Bild ist die Beschreibung des Systems dargestellt. Die Beschreibung beginnt mit dem Modul »Einbruchmeldesystem«. Die Systemstruktur-Beschreibung ist, beginnend vom »Backbone«, hierarchisch aufgebaut. An dem Backbone ist die Einbruchmeldezentrale angeschlossen, diese ist mit dem Feldbuskoppelmodul über den internen Bus verbunden. Die Sensoren kommunizieren über den Feldbus mit dem Feldbuskoppelmodul.

134

E. Noak, S. Jovalekic, H. Grochowski

Einbruchmeldezentrale

Bewegungsmelder

02

27 Feldbus

Glasbruchsensor

Backbone

Interner Bus

Feldbuskoppelmodul

<module name = "Einbruchmeldesystem"> <module name = "Einbruchmeldezentrale"> <module name = "Feldbuskoppelmodul" type = "Koppler" address = "02"> <module name = "Bewegungsmelder" type = "Sensor" address = "27" .../> ….. ……

Gebäudesicherungssystem (Ausschnitt)

Systemstruktur-Information

Abb. 4: Beispiel eines Testobjektes mit Konfigurationsbeschreibung

4 Konfigurationsabhängige Protokollanalyse 4.1 Protokollanalysesprache Die erfassten Nachrichten werden in hexadezimaler Form in der Datenbank abgespeichert. Eine manuelle Analyse dieser Rohdaten ist selbst für erfahrene Entwicklungsingenieure sehr schwierig und zeitaufwendig. Aus diesem Grund werden diese Rohdaten automatisch mittels Protokollanalyse in eine verständlichere Form transformiert und dargestellt. Die Struktur der Rohdaten ist vom Kommunikationskanal und dem angeschlossenen Teilnehmer abhängig. Um viele Möglichkeiten abzudecken, wurde eine allgemeine Protokollspezifikationssprache basierend auf der Metasprache XML festgelegt und entwickelt. Bei der Konzeption der Sprache wurde darauf geachtet, dass die Transformationsprogramme, sog. Filter, für die Umwandlung der Rohdaten in Fertigdaten mit wenig Programmierkenntnissen relativ schnell zu erstellen sind. Die Sprache enthält Elemente für Textdarstellung, bedingte Verarbeitung, komplexe Fallunterscheidung, Verweise, Schleifen und längenabhängige Verarbeitungen. Zu jedem der Übertragungsmedien wird ein Filter in dieser Sprache erstellt, mit dem die Nachrichten zerlegt und interpretiert werden. Abb. 5 oben stellt die Nachrichtenliste dar. Eine Nachricht enthält die Kommunikationskanalnummer (Channel), die Systemidentifikationsnummer (SystemID), den Zeitstempel (Timestamp) und die Nachrichtendaten (Data). Die Felder Quelle (Source) und Ziel (Destination) geben die Adressen der beteiligten Komponenten an. Im unteren Teil der Abbildung wird die Zerlegung der selektierten Nachricht mittels Protokollanalyse dargestellt. Das Beispiel zeigt den Zustand eines Gerätes mit 5 Eingängen. 4.2 Konfigurationsabhängige Protokollanalyse Für jeden Teilnehmer wird ein Filter definiert, der die Messdaten in eine lesbare Form transformiert. Sobald die Konfiguration der Anlage geändert wird, ist man gezwungen, ein neues Filter zu spezifizieren oder ein vorhandenes Filter anzupassen. Bei einer überschaubaren Anzahl von Konfigurationen hält sich der Änderungsaufwand noch in Grenzen. Wenn aber eine Anlage frei konfigurierbar ist, ist der Aufwand immens hoch. Abhilfe schafft eine konfigurationsabhängige Protokollanalyse. Diese verwendet

Protokollanalyse und Informationsflussverfolgung in verteilten Echtzeitsystemen

135

Abb. 5: Protokollanalyse einer Nachricht

zusätzlich die herstellerspezifische Systemstruktur-Beschreibung der Anlage. Sie wird mittels eines Export-Tools in eine herstellerneutrale Beschreibung überführt. Diese wird bei der Protokollanalyse verwendet. Die empfangenen Nachrichten enthalten die Absenderadresse, aber keine Information über den Absender. Anhand der Adresse kann die Komponente der Anlage durch die Systemstruktur-Beschreibung eindeutig identifiziert werden. Aus den Konfigurationsdaten des Testobjektes wird die Typidentifikation der Komponente ermittelt, die der Identifikation des Subfilters dient. Das Subfilter stellt die Nutzdaten einer Nachricht dann in lesbarer Form dar. In Abb. 6 ist die Interpretation von Rohdaten durch ein adressenabhängiges Filter dargestellt. Aus den Headerinformationen wird die Adresse des Absenders ermittelt. Mit Hilfe dieser Adresse wird in der Konfiguration nach der Komponente gesucht, die diese Adresse besitzt, und deren Typ zurückgegeben. Der ermittelte Typ entspricht der Identifikationsnummer des Subfilters, das dann für die Interpretation der Nutzdaten der Nachricht verwendet wird [6] [8].

5 Unterstützung der Informationsflussverfolgung 5.1 Ereignisliste Mit der Systemstruktur-Beschreibung ist es möglich, die Zusammenhänge zwischen den Informationen an verschiedenen Stellen im verteilten System zeitlich zu verfolgen und verständlich darzustellen. Diese Informationen werden tabellarisch als Ereignisliste dargestellt. Man benötigt lediglich die Sende- und die Empfangsadresse der Nachrichten. Alle anderen Informationen werden der Systemstruktur-Beschreibung entnommen.

136

E. Noak, S. Jovalekic, H. Grochowski

Nachricht erfassen (42 01 1F 62)

42 01 1F 62

Sendeadresse ermitteln (2) Gerätetyp anhand der Konfiguration ermitteln Aufruf des Subfilters anhand von Typ (2)

Adresse 2 Typ 2

5 AM (Typ 1)

5 EM (Typ 2)

Nachrichteninhalt interpretieren (1F)

LCD-Bedienteil (Typ 15)

Abb. 6: Interpretation der Nachricht

Die Ereignisliste enthält die empfangenen Nachrichten mit zugehörigen Zeitstempeln innerhalb der Ursache-Wirkungs-Kette vom Ursprung (Sensor) bis zum Ziel (Aktor) der Verarbeitung.

Abb. 7: Ereignisliste

Die linke Spalte »Datum/Uhrzeit« in Abb. 7 enthält den Zeitstempel. Die rechte Spalte enthält den natürlichsprachlichen Text zur Erläuterung des Ereignisses. Das erste Ereignis sagt aus, dass das Modul »Bewegungsmelder« mit der Adresse 27 eine Nachricht über das Modul »Stich C« und der Verbindung »Feldbus« an das Modul »Buskoppler« mit Adresse 2 sendet [9].

Protokollanalyse und Informationsflussverfolgung in verteilten Echtzeitsystemen

137

5.2 Impulsdiagramme Ein Impulsdiagramm liefert durch graphische Darstellung einen besseren Überblick über die empfangenen Daten. Dadurch soll die zeitbezogene Offline-Analyse in einem verteilten Echtzeitsystem erleichtert werden. Die Daten sind zeit- und kommunikationskanalabhängig dargestellt. Die einzelnen Impulse über der Zeitachse stellen die Nachrichten zwischen den Busknoten dar.

Backbone

t/ms Feldbus 4B 01 01 4D

t/ms

Abb. 8: Impulsdiagramm

Abb. 8 zeigt das entwickelte Impulsdiagramm. Die Bedienelemente sind im oberen Bereich der Anwendung platziert. Die Messdaten werden durch die Anfangszeit und die Zeitdauer definiert und aus der Datenbank geladen. Für jeden Kommunikationskanal wird eine neue Zeitachse erzeugt. Es werden Scroll- und Zoomfunktionen zur Verfügung gestellt. Beim Zoomen und Scrollen laufen die Koordinatenkreuze synchron zueinander. Im Beispieltestfall sendet der Bewegungsmelder die Nachricht »Bewegung« auf den Bus »Feldbus«. Die Einbruchmeldezentrale empfängt diese Nachricht und sendet die Nachricht »Einbruch« auf den Bus »Backbone«. Impulsdiagramme bieten, durch genaue zeitliche Beziehungen von Ereignissen zueinander, zusätzliche Diagnosemöglichkeiten an. Durch die graphische Ausgabe wird ein schnellerer Gesamtüberblick und eine übersichtliche Darstellung erreicht.

6 Danksagung Die Autoren danken dem Ministerium für Wissenschaft, Forschung und Kunst des Landes Baden-Württemberg für die finanzielle Unterstützung des Projektes. Unser Dank gilt auch Bernd Rist, Honeywell Security Deutschland für die Unterstützung bei der Definition und Validation, dem Studenten V. Fernandez von der Universität Vigo, Spanien und den Projektstudenten A. Laich, C. Goutsis und T. Picard für deren Arbeiten bei dem Entwurf und der Realisierung von Teilen des Testautomatisierungssystems.

138

E. Noak, S. Jovalekic, H. Grochowski

7 Zusammenfassung und Ausblick Der zeitbehaftete Ursache-Wirkungs-Graph bildet die Grundlage für das Verfahren »Informationsflussverfolgung«. Dabei wird der Informationsfluss an verschiedenen Orten auf korrekten Inhalt und Zeitbedingungen überprüft. Das Verfahren »erweiterte Informationsflussverfolgung« betrachtet die interne Struktur des Testobjektes. Diese wird durch Module und Verbindungen beschrieben. Die konfigurationsabhängige Protokollanalyse der erfassten Nachrichten nimmt Bezug auf diese Strukturbeschreibung des Testobjektes und liefert Ergebnisse auf einem hohen Abstraktionsniveau. Statt kryptischer Bitfolgen werden dem Entwickler natürlichsprachliche Texte für die Fehlersuche zur Verfügung gestellt. Die empfangenen Nachrichten werden hierzu tabellarisch als Ereignisliste dargestellt. Zur Beurteilung des Zeitverhaltens und Identifikation möglicher Fehler wurden die Impulsdiagramme konzipiert. Alle diese Zusatzfunktionen verbessern wesentlich das automatische Testen von verteilten Echtzeitsystemen. Die Testobjekt-Strukturinformationen können auch bei der Testplanung genutzt werden. Hierfür sind zusätzliche logische Angaben in Form von Wertebereichen und zeitliche Angaben in Form von Verarbeitungs- oder Übertragungsdauer erforderlich. Die Integration dieser Information stellt eine Herausforderung an zukünftige Forschungsarbeiten dar.

Literaturverzeichnis 1. Spillner, A.; Linz, T.: Basiswissen Softwaretest, dpunkt.verlag 2007 2. Bender, K.; Pöschl, M.; Danzer, B.; Kausler, B.; Spiegelberger, B.; Ivanova, N.: TeCom Testfallcompiler für den Funktionstest eingebetteter Systeme, Forschungsbericht Nr. 24/2006, Deutsche Forschungsgesellschaft für die Anwendung der Mikroelektronik e.V. (DFAM). 3. Drath, R.; Fedai, M.: CAEX - ein neutrales Datenaustauschformat für Anlagendaten-Teil 1,2; atp 46 (2004) Heft 2; S. 52-56; Heft 3; S. 20–27 4. Rist, B., Poganatz, D. und Jovalekic, S.: Testautomatisierung verteilter echtzeitfähiger Systeme basierend auf einer graphischen Testplanbeschreibung, in Haasis, Heinzl, Klumpp (Hrsg.), doIT Software-Forschungstag 2006, S. 241–255, dpunkt.verlag, 2006. 5. Jovalekic, S.; Rist. B.: Modellbasiertes Testen verteilter Automatisierungssysteme mittels Informationsflussverfolgung, Kongress der Gesellschaft für Mess- und Automatisierungstechnik 2007, 12/13. Juni 2007, Baden-Baden, VDI-Berichte Nr. 1980, 2007, S. 387–396. 6. Jovalekic, S.; Rist. B.: Test Automation of Distributed Embedded Systems Based on Test Object Structure Information, 25th Convention of Electrical and Electronics Engineers in Israel, Anthony J. Weiss (Hrsg.), IEEE 2008, S. 343–347. 7. Dietrich, C.; Schmidt, D; Simon, R.; Thron, M; Wollschlaeger, M.:, XML für Wartung und Engineering Busgekoppelter Komponenten, DFAM Forschungsbericht Nr. 20, 2003 8. Noak, E.: CAE unabhängige Systemstruktur Beschreibung zur Testausführung wertdiskreter verteilter Echtzeitsysteme, Diplomarbeit WS 2008/2009, Hochschule Albstadt-Sigmaringen 9. Grochowski, H.: Ereignisliste zur Darstellung der zeitlichen Abfolge von Nachrichten in einem verteilten Echtzeitsystem der Gebäudesicherungstechnik, Diplomarbeit SS 2009, Hochschule Albstadt-Sigmaringen